Artificial intelligence is going to redefine how humans experience work. I think in a positive way.
But we need two things to get there.
First, we need to make it dead simple to build artificially intelligent systems1. That means reducing the number of moving parts and perfecting the few that actually matter.
Second, we need to design a developer experience so focused that builders spend nearly all their time improving intelligence, and almost none on anything else.
This is where AGI will actually come from. Not from a single model, at least not any time soon. It will emerge from perfecting the foundation for building intelligent systems, maximizing the time builders spend using them, and ultimately enabling those systems to build and improve themselves.
Astral exists to make that future possible. We’re rebuilding the AI development stack from the ground up. That starts by understanding what’s broken, then rethinking what the stack actually needs to support this new way of building.
What I Learned the Hard Way
I’ve spent the last 18 months building intelligent systems for startups. And every project felt the same. I spent more time wrestling with tools than building anything useful.
The problem wasn’t just the tools. It was getting them to work together. I was using four different services to call models, rewriting integrations to reach external systems, juggling tracing setups, and still struggling to get anything into production. Nothing worked end to end.
Eventually I got sick of it and started building my own tools. Not to start a company. Just to make my own work easier.
Each one solved a different problem, but they all spoke the same language and shared a common foundation. I didn’t realize it at the time, but I was starting to answer a deeper question: what are the core pieces needed to build intelligent systems?
As these tools started to compound, I was building in hours what was taking other teams weeks. More projects started coming my way, mostly from YC startups. A few asked me to join full time. I turned down four offers, including a CTO role, to keep exploring what these tools could become.
Eventually I joined 1Mind, where I had the freedom to keep building. The systems I built became core to how the company operated and helped drive it to $1 million in ARR.
That's when I realized it wasn't just me. Everyone building intelligent systems was hitting the same wall. You only get two bad options.
The first is to stitch together a pile of fragmented tools like I was doing. None of them work well together. And as the system grows, the complexity only gets worse.
The second is to use a platform from a big vendor like IBM or Microsoft. You get some unification, but at the cost of flexibility and control.
Rethinking the Stack
As I’ve said before, we want a future where intelligent systems can build and improve themselves. To get there, we have to rethink the stack from first principles.
What does it actually take to build high-performing intelligent systems?
Surprisingly little. Just three core layers, and one capability that runs through all of them.
The Model Layer
This layer is pretty straightforward. Models are the intelligence in intelligent systems. They take in context and produce an output. Everything else exists to support that process. So it makes sense to start here.
what’s not so simple is what you need from this layer.
First, you need to be able to use any model from any provider. Different models are good at different things. Some excel at reasoning. Some at coding. Others are finetuned on your own data. We see models as a new form of talent. The best developers will reach for the best model for the task, which is often one that just launched. So you also need instant access to every new model release.
Second, you need a standard way to connect models to external systems. That is where the Model Context Protocol2 comes in. I won't get into the weeds, but MCP gives you consistency in how models access tools and data. It eliminates custom integrations and lets systems stay simple as they scale.
Third, you need resilience. Providers go down. Latency spikes. But the system still has to work. You should be able to route around issues automatically, the same way you would with any reliable infrastructure.
The Orchestration Layer
Once you can use any model, the next question is how you use them. That is the job of the orchestration layer.
Orchestration is about structure. You take intelligent decisions and put them into some repeatable form. We see these fall into two buckets: workflows and agents.
It is important to keep a clear distinction between the two, both in how you think about them and how you implement them. The clearest thinking I've seen on this comes from Anthropic, who stress the importance of keeping workflows and agents distinct. I agree.
The key is to keep things simple and composable. Workflows and agents should both build on the same model layer. Sharing a common foundation makes systems easier to understand, debug, and scale.
Most frameworks don't get this right. They bury logic across abstracted layers or lock you into a single provider3. That may work for prototypes, but it limits you as systems grow. We share Anthropic's view: "frameworks often introduce layers that obscure the core prompts and responses, making them harder to debug."4
This is where simplicity earns its keep. The fewer moving parts a system has, and the more they're built on a shared foundation, the easier it is for other intelligent systems to understand it and improve it.
The Deployment Layer
Once you can build intelligent systems, you need a way to run them. That's the role of the deployment layer.
Deployment should be simple. One command should take you from a prototype to a running system. Think of the experience Vercel brought to web applications, but applied to intelligent systems.
But simplicity should not come at the cost of flexibility. You should be able to run your code anywhere. That includes serverless platforms like AWS Lambda, containers on GCP or Azure, or on-prem in your own environment.
Finally, deployment should fit naturally into how teams already work. That means integration with popular version control platforms. You should be able to push changes, track history, and roll back when needed.
Observability and Evaluation
Observability is the feedback loop that runs through the entire stack. Intelligent systems behave less like traditional software and more like people. But unlike people, they need constant observation. You need to see every decision they make: what happened, when it happened, and what context it had at the time.
You also need to experiment constantly. Try new prompts. Swap in different models. Add or remove tools. Progress depends on the speed of iteration.
Finally, you need to track usage, cost, and performance. As systems scale, so do the risks. You need a clear view of what is running, what it is costing, and whether it is creating value.
Rebuilding the Stack
I know I’ve said this a few times already, but it's worth repeating.
Our goal is to make it dead simple to build intelligent systems. The simpler it is, the more likely we reach a future where those systems can build and improve themselves.
We’ve now walked through the raw ingredients. But turning that thinking into something real is still not straightforward. So let me rewind. As I mentioned earlier, the tools I'm about to walk through didn't start with the goal of becoming a platform. They started as a way to make my own work easier. Each one solved a real problem I kept hitting while building intelligent systems for startups. I just needed things to work better, and once they did, I realized the potential of what I was building.
Each tool does one thing exceptionally well. Each maps to a clear part of the stack. And most importantly, they all speak the same language. That shared foundation is what keeps the system simple. It's what lets builders spend their time improving intelligence and what opens the door to systems that can eventually build and improve themselves.
Astral Core
This is our model layer. It is a Python library that gives you one interface to any model, from any provider. The library implements the Model Context Protocol to standardize how models access tools and data. It's also capable of routing around provider outages and latency spikes.
Other routers exist, but most wrap legacy APIs, few support MCP, and almost none offer a clean, provider-style developer experience. And most importantly, none work well with the rest of the stack.
Astral Agents SDK and Astral Workflows SDK
This is our orchestration layer. Earlier, we stressed how important it is to keep agents and workflows distinct, and to build them on a shared foundation. These SDKs do exactly that. Each offers a simple interface for its own kind of system. Both follow the same structure and syntax because both are built on Astral Core. That makes them easier to understand, easier to debug, and easier to work across.
Most agentic SDKs are weighed down by abstraction, or only stay simple when locked to a single provider. Ours stay minimal while offering all models and providers.
Astral Deployment
This is how intelligent systems move into production. Today, it’s a small set of configurable Infrastructure as Code (IaC) scripts for AWS. Over time, it will grow into a full deployment layer that runs on any runtime, from serverless to containers to your own machines.
Hardly any Python tools treat deployment as a real layer for intelligent systems. And none do it while supporting everything underneath.
Astral Observability
This is visibility across every layer. You see every model call, agent decision, and workflow step in one place. You also get usage, latency, and performance.
A lot of teams are building observability frameworks, but they’re doing it as outsiders. That means every time a layer changes, you have to rework everything. This is the advantage of building the stack from the ground up.
The best part is, it's not even a separate component. It's built into the three layers above. There's nothing extra to install. And if you don't want it, just set an environment variable to turn it off.
Why This Wins
What sets us apart is our consistency across every layer. Each part of the system speaks the same language. That’s what makes it easy to build with, and even easier to scale.
Most tools try to solve just one layer - and we see real advantages within each of those buckets. But our true leverage comes from owning the stack.
When the layers are designed to work together, you get a lot of leverage. You spend less time gluing things together, and more time focused on the actual intelligence.
That’s what will eventually make it possible for intelligent systems to build and improve themselves.
How We'll Get There
So the question now is how we bring it to life. We’re taking a three-phase path.
First, we’re building for others. We’re working closely with teams to design and deploy intelligent systems using the internal tools we just walked through. This gives us fast feedback loops and proves the leverage the system creates.
Next, we’ll turn those tools into a unified platform. One that gives developers and teams everything they need to build, run, and evolve intelligent systems.
And once the platform is mature, we’ll use it to build the machine that builds the machine. That's the long-term goal. A compounding engine of intelligence, built from simple, modular parts.
Phase One: Implementation
Right now, we're using our own SDKs to build workflows and agents for companies. It doesn't scale forever, but that's the point. I'm a firm believer in doing things that don't scale early on. The problem we're solving is hard, and being the first and heaviest users means our feedback loop is instantaneous.
This also lets us prove how much leverage the system creates. We’ve already signed a deal with a late-stage startup to build and maintain a custom AI workflow. I built the initial version in a single day, working solo. The contract covers both implementation and ongoing maintenance, and the time required each week is minimal. The return on time is unlike anything I’ve seen in software.
The goal now is to close 3-4 more of these implementation deals. We're targeting late stage startups and mid market software companies, using warm intros and targeted outreach to get in the door.
At the same time, we're raising a $1 million initial round. That gets us our first office and locks in a founding team of two engineers and one exceptional generalist. I'm firm in my belief that building a startup is very difficult. Trying to do it remote only makes it harder. I want our founding team in the same room.
Phase Two: Platform
During our early implementation deals, we'll package our internal tools into the Astral platform. It will include our core Python library, two SDKs for agents and workflows, and a single CLI for managing resources, deployment, and observability. On top of that, we'll offer a hosted console for deploying and managing intelligent systems. Think of the experience Vercel created for web apps, but applied to AI.
From here, we're going to have a relentless obsession with developer experience. Everything else will work backwards from that. But what does that actually mean?
First, we're going to have the simplest quick start in the industry. A clear, step-by-step flow to build and deploy your first workflow or agent with Astral. Backed by world-class documentation, end-to-end guides, and walkthroughs. This is what modern developers expect, and we're going to surpass it.
We're also going to live in developer spaces, both online and in person. Hackathons, events, Reddit threads, Discord groups. Anywhere builders are, we'll be there too. From there, we'll grow our own developer community. It will start on Discord and expand through real-world events. Me and the early team will be in it every day. Answering questions. Fixing bugs. Sharing progress. Obsessively active.
Exceptional design is still an early thought in this space, but already proven to be a real advantage. Look at Linear, Vercel, Next.js, ShadCN, and Motion. They win because of how their products feel. Astral will be the same. We'll start with how we want it to feel and build backwards from there.
Phase Three: The Machine That Builds the Machine
Once the platform is stable, we'll use it ourselves to build agents and workflows that can improve other intelligent systems. This is the flywheel we're building toward and it gives us leverage on both sides of the business.
On the platform, it lets us layer intelligence on top of existing usage. Just like Notion did with Notion AI. We start with infrastructure buy-in, then add systems that help you build and operate more effectively. This increases our recurring revenue from existing customers.
In implementation, it compounds what we already have. We've proven we can sell high-leverage systems. This only improves margins and shortens delivery time. Put simply, this is the worst the Astral system will ever be. Everything from here gets faster and more intelligent.
It also opens new markets. Once we have the platform and intelligence, we can deploy our own agents directly to businesses and consumers. These agents become products in their own right. Think of it as a long-term engine for launching new workflows and capabilities, powered by everything we've already built.
Where We're Headed
We're going to move fast but carefully. We could have built a vertical agent that generates other agents. It would have been faster to ship. But we're choosing the harder path.
Rebuilding the stack from the ground up gives us an immense long-term competitive advantage.
It’s worth repeating. We’re setting out to make it dead simple to build intelligent systems. That’s how we reach a future where those systems can build and improve themselves. Everything we are building—our libraries, our platform, and our path—is in service of that goal.
Thank you for reading.
Footnotes
- 1.We use the term “intelligent systems” throughout this piece. In most cases, we’re referring to workflows and agents, which are defined clearly in 4.
- 2.
- 3.Even Google and OpenAI's SDKs fall short unless you commit to their entire ecosystem
- 4.