Founder @tensorlake, building sandbox infra for agents. Past - Built Nomad @hashicorp, AI Infra @meta, Container Scheduler tech lead @linkedin and @netlfix
This is the first time I've spoken publicly about getting acquired by AWS, why we're building Hercules, and my journey as an entrepreneur.
Honored to do it with my friend, @moritzplassnig (CEO @CloudBees) as he relaunches the @codeship brand!
Timestamps:
- 0:00 Intro
- 3:52 How Fig started
- 9:00 Betting on autocomplete
- 10:55 Getting acquired by AWS
- 16:30 Navigating the idea maze
- 19:26 Zeus: Palantir-like enterprise AI transformations
- 22:42 Hercules: The best AI app builder for business
- 26:41 Reaching 10s of millions of revenue with 7 people
- 37:41 Our emphasis on customer support
- 40:46 The SaaS-pocalypse
- 45:19 Closing thoughts
Transcript: https://t.co/b6rSqqlYYU
We’ve been deep in building an SDN for sandboxes.
When this lands, you’ll be able to enable a private network of sandboxes with firewall rules, connect them to your internal AWS VPCs via WireGuard, and most interestingly let coding agents stand up system environments similar to what you’d expect in production, instead of running services in Docker images inside the sandboxes.
Seeing a lot of posts that CI needs a lot of compute, so you can run your CI on X, Y, and Z sandbox platform and cut your bill by 1/3rd.
I think you will be surprised how much other things matter too:
1. Good bandwidth to Azure/Microsoft if your code lives in GitHub.
2. Efficient VM snapshotting to do a “sticky disk” type thing.
3. Package caching on the network.
4. Carefully managing oversubscription, or not oversubscribing at all, because compilers often use all the CPUs you can throw at them.
5. A distributed file system for storing caches, because CI is all about caching expensive steps.
CI is all about caching, so cheap compute without all of this would still slow your team down. The winning combination would have a fast distributed file system, cheap compute, no oversubscription of resources, vertical scaling to keep the sandboxes small when caches and being restored and scale up quickly when running compilers.
🚨 LiteLLM, a Python package for connecting to AI model providers with 92M+ monthly downloads, has been compromised.
Version 1.107.0 ships credential-stealing malware through PyPI wheels and Docker images, targeting cloud credentials, developer secrets, and AI tools.
If the state machine itself is executable, you don't need an agent to translate code to TLA+ to verify it. The runtime that executes it verifies it.
I'm working on something called UniKon (universal constructor, shortened the Japanese way): a multiplayer workshop where agents build apps that are malleable and self-improving as you (or agents) use them. Any agent can join over MCP, and they all work on the same state.
UniKon app runs on Temper runtime (by @nerdsane): every app is an executable statechart of policy-controlled state machines. Agents write them, Temper verifies and executes them.
Powered by @tensorlake for persistent scalable sandboxes, @tursodatabase for durable storage, with @datadoghq watching it all and paging @bot directly.
This is my factory for building UniKon, a bit meta, it itself is a UniKon app that runs the SDLC for UniKon. Every agent working on UniKon for me shares this app as a tool and keeps evolving it toward what it needs. It's a machine tool for tools, hence "universal constructor".`
Coming soon to @tensorlake !
We will manage windows licenses and offer Windows Sandboxes which agents can control remotely and work with Windows apps like Office, Powerpoint and Excel sheets.
You can now vertically scale running sandboxes on @tensorlake. This was one of the most requested features for building coding agents. Sandboxes can now adapt to the workload on the fly, instead of relying on static resource configuration.
The live DuckDB workload in the demo scaled up by 7x in throughput when its CPU and memory were increased live. If the machine running the sandbox doesn’t have enough capacity, the sandbox is transparently migrated to a node that can meet the new resource requirements.
We're hiring a founding growth (engineer?) for @tryreplicas in SF.
@SaaiArora and I are both engineers. We'd never done growth before and had to scale the business through founder-led sales and iterating over and over and over (e.g. learning SEO/GEO, outbound)
We're at an important inflection point on the company, and want an incredible growth hire to light the fuse
What you'll do:
> Launch, launch, launch
> Help me data monkey on ads, SEO/GEO, etc.
> Run events
> Figure it out
I am curious how do you solve this problem? I think the data has to live outside the environment, and the database/store has to support forking the way sandboxes do. We are working on TLFS for this, it's a versioned file system that sits on top of object stores. For it to be used in petabyte scale environments it needs to be really good so that people can start using it as disks for databases and warehouses, then forking it to use in environments would be feasible. Otherwise cost of moving data between source of records and environments is going to be too much.
Excerpt from the agentic monitoring post on HN (link in 🧵): we piloted this last week for one of our customers.
A background agent sweeps logs every hour, generates a system health report for sandboxes, and spawns sub-agents to dig deeper or even create PRs for anything that feels off.
Each sub-agent runs in an isolated sandbox/harness and can run as long as needed while the parent goes back to sleep. Sub-agents can also wake the parent sweeper to reconcile findings and update the report.
My first reaction was that it produces an overwhelming amount of data; we’ll have to dial it down to the things that move the needle for customer-perceived reliability.