The Agentic OS: a first‑principles approach to building agents that get things done

AI agents are remarkable. They’ve given us the ability to reason over complex, multi-dimensional knowledge and capabilities across an organization, and take actions at a scale that previously demanded far more time and resources. My role gives me the privilege of sitting at the intersection of business and technology, and observing firsthand the compounding value agentic thinking creates for our business, and for our customers.

There is a meaningful gap, though, between agents that demo well (AI always demos well) and agents that actually move the needle. This post is about our own journey towards becoming an AI-native company, the lessons we learned along the way, and the intentional, iterative, first-principles approach that was needed to apply these ideas across multiple, complex problem spaces.

Crossing the Chasm

We have all been here. Early prototypes generate excitement (AI always demos really really well). Leadership sees the potential. And then come the “real” questions that are harder to answer:

• Scaling. How does this go beyond the first few use cases?
• Adoption. How do people actually use this in their daily work?
• ROI. What is the value?
• Token economics. What is the cost of running these systems at meaningful scale?

This entire arc has played out at hyperspeed in the last ~12-18 months. It is natural to see this shift driven by a P-Type technological innovation, and inevitable to reach out only for technological solutions.

Problem Space: The Sales Machinery

We have applied this thinking across multiple problem domains inside the organization. For this article, I want to spotlight one that I think is particularly illustrative: running a moderately complex enterprise sales motion.

A sales machinery is an interesting problem space for agents: its shape can be fairly symmetric across organizations. There are usually well-defined stages, typically captured in a CRM and explicitly defined. A large group of people, across myriad job roles, are orchestrating towards a common outcome. There is a rich ecosystem of tools (often more than you need 🙂) that each hold a fragment of the overall customer picture. And the outcomes are high-value and measurable.

Most complex business operations share these structural properties, and the patterns that emerge here are not unique to sales.

The problems in these machineries also end up having a certain amount of symmetry to them. Context dies at every handoff between teams, stages, and systems, leading to quite a bit of repetitive work. Insights get generated but do not convert into action. It is often hard to piece together a single canonical view of the customer. And risk surfaces too late, because humans are not naturally incentivized to share bad news early. These are all expressions of the same underlying friction: context degrades every time it passes through an intermediary.

That combination of structural symmetry and persistent context loss is what makes building an AI-native sales machine a natural fit for agentic solutions.

Let’s build some Agents!

What happened next was exactly what you’d expect from any team enthusiastic about building agents and solving customer problems. Our forward-deployed engineering team took a hackathon-style approach: brought in stakeholders from across the sales organization, carved out a couple of weeks, and just started building. We built a bunch of agents, covering different parts of the sales motion. The demo day was awesome.

The real signals came when we started putting these agents into actual workflows. As we moved from controlled demonstrations to real usage, seams and rough edges started to show. Agents that looked impressive in the demo struggled to produce consistent, trustworthy output in the field. The surface area of the problem turned out to be larger and more nuanced than the prototypes had suggested.

Three lessons came out of the retrospection that followed, and they fundamentally shaped how we think about building agents.

Lesson One: Agents with “discrete end states” performed best

The agents that had a discrete, observable end state outperformed everything else. And they did so by a wide margin.

A win-loss analysis agent, for example, operates against a known outcome: the deal was won or lost. That is a fact. A smart model can reason backwards from that endpoint through call transcripts, competitive signals, and pipeline history, and produce a genuinely insightful answer. In these cases, model intelligence mattered, probably even more so than the quality of context that was brought in by the domain experts or the engineers. A smarter LLM significantly outperformed a cheaper one.

For agents that did not have a discrete end state (where the end state was much further down the pipe), like lead qualification or early-funnel discovery, a smarter model did not necessarily produce a better answer. It produced a more articulate answer, a more confident answer, but not one that was demonstrably closer to the truth. Because there was no observable ground truth to anchor against, intelligence expressed itself as fluency rather than accuracy.

This was completely obvious in hindsight, but I must admit, not so in foresight, and I suspect most teams building agents today are learning this experientially.

Without an observable outcome, intelligence is difficult to distinguish from plausibility.

Lesson Two: A2A?

The natural follow-up to Lesson One was: if agents further down the pipeline have access to observable end states, why not let the early-funnel agents talk to them? A lead qualification agent does not know whether a lead eventually converts. But a win-loss agent does. So either give the upstream agent access to downstream tools and data, or give it the ability to call the agent that already knows the answer. Agent-to-agent.

Anyone who has built a complex distributed system recognizes the shape of what comes next. Every agent we had built was independently solving the same integration problems: five agents, five separate connections to Salesforce, five separate retrieval pipelines. And now we were about to add a mesh of agent-to-agent edges on top of that. If this reminds you of something, it should.

After spending the last decade-plus in the APIs and Microservices space and seeing (+ experiencing) my fair share of “Death Star architectures”, I can say with confidence “edges are hard”. At scale, over meaningful time, they become really hard. Agent-to-agent communication has to be intentional, reserved for boundaries that are genuinely outside your scope with interfaces designed around that contract, and not the default pattern for agents operating within the same domain, on the same data, for the same organization.

What we were ideating was not a network of specialists collaborating. It was isolated agents assembling fragments of the same picture, then sharing partial views through message-passing. Coordinated ignorance, not shared intelligence.

In dependency-hell architectures, the only thing that compounds is cost.

Lesson Three: How do you define boundaries?

But the question that kept irking me through all of this was more fundamental: have we drawn the code boundaries correctly? We had carved out agents (and their logic) almost orthogonally to pipeline stages. That felt natural, and it mapped cleanly to how the sales teams thought about their own work, hence the logical boundaries, right?

But when we looked more closely at what these agents were actually reasoning about, every single one was working with the same underlying entities: the account, the deal, the champion, the outcome. The vocabulary was identical across all of them. The data was overlapping. The only thing that differed was the question being asked and the human asking them.

Domain Driven Design thinking taught us that if two systems share the same language and reason about the same entities, they are not separate domains. What we had was not nine domains. It was nine phases of a single domain, with one persistent entity at its center: the customer account. Every agent should reason over the same canonical domain model, while receiving a policy-scoped view of the underlying state.

Agent-to-agent communication is appropriate as a controlled, contract-bound implementation pattern. It is inherently complex as an emergent peer-to-peer topology inside a single domain.

The error surface was decomposition, not orchestration.

Isomorphism: an eternal golden braid

Why did most agents underperform when they did? The natural instinct was to look at the technology. Tune the prompts. Upgrade the model. Improve retrieval. But when we actually traced the underperformance, the root cause was frequently sitting in a completely different layer.

We started examining every problem through four lenses simultaneously: business (process shape, incentives, end states), product (the users, their JTBD, the why), technology (agents, data, retrieval, evals), and people (who builds, who judges, proximity to the problem). These four layers are isomorphic. They reflect and constrain each other, and they cannot be optimized in isolation.

The practical consequence of this is that a problem surfaces in one layer, but its root cause frequently sits in another. “The agent is producing bad output” looks like a technology problem. When we traced ours, the technology was often fine. The end state had never been clearly defined (a business problem). The agent did not know what the company actually sells or to whom (a product problem). Or the person building the agent was three steps removed from the process it was meant to serve (a people problem).

This lens changed how we approached the redesign entirely. It gave us permission to stop patching individual agents and instead rethink the architecture from a more holistic standpoint.

The architecture is not merely a technical platform. It is a system for assigning institutional ownership:

• Who defines what good looks like?
• Who maintains current strategy?
• Who decides which behavior is unacceptable?
• Who is accountable when the system is wrong?

Agentic OS

The redesign centered on one conceptual shift. Instead of building independent agents for each part of the process, we would build a “family of agents”: a set of specialists that collectively serve the one domain, standing on one shared platform. The platform provides every agent at the baseline, the same memory, the same grounding, the same strategic context, and the same guardrails.

What follows covers the broader architectural patterns and the reasoning behind the key decisions. There is a fair amount of engineering depth underneath each stage that goes beyond what this article can cover. The stages are presented sequentially because we were very intentional about layering complexity into the system. At each stage, we rolled out a set of capabilities, observed the limitations, and introduced a new architectural construct to address them.

Stage 1: The Monolith

Simplify. We consolidated our 15-odd specialist agents into one: a single “monolithic” agent (co-pilot, not autonomous), that could answer questions across all the surfaces and data sources in the system. To achieve this, we introduced two architectural elements:

1. Knowledge. Queryable aggregation with pathways to go deeper. Content from each connected system is summarized and vectorized, with pointers maintained back to the underlying sources. When the agent needs more depth on a specific signal, it can follow those pointers and retrieve the detail from the source system directly.
2. Intelligence is how the agent reasons over that knowledge. This involves the choice of model, the system prompt, decision trees that guide when to use which tool, and tool guidance that defines how each tool should be called. As you can imagine, this layer requires a fair amount of optimization: prompt engineering, model selection, retrieval tuning, and tool orchestration are all dials that interact with each other. Getting this right was iterative.

What worked was genuinely impressive. For the first time, you could ask a single question (of meaningful complexity) and get a cross-cutting answer synthesized from sources that had never been connected systematically before. Patterns that no individual human could see became visible, and the monolith made it all queryable from one place.

BUT, the agent hallucinated over multiple layers of data and tools. It was very much a generalist rather than a specialist, which meant it was decent at everything and excellent at nothing. And it was far too knowledgeable to safely open up to a wider audience.

It was a brilliant research assistant in the hands of “capable & maximally aware” humans, but not an agent you would democratize or trust to act independently.

Stage 2: Decomposition – Shared substrate, specialized roles

To solve for these, we introduced four new architectural elements:

1. Anti-Hallucination Provenance. We added a dedicated verification layer that cross-references every claim the agent makes against its source material. If a response cannot ground itself in citations, it gets discarded and the agent retries. This is not an instruction in the prompt telling the agent to be careful. It is a separate, narrowly scoped agent whose only job is to check provenance. The reason this works where inline instructions do not is scope: the main agent is juggling an enormous context in which any single instruction can drown. The verifier does one thing, with no competing priorities.
2. Monorepo. Rather than giving each specialist its own codebase, we implemented the shared substrate in a monorepo so every specialist inherited the same integrations, retrieval patterns, policies, and runtime.
3. Domain-specific Agents: Personas and JTBD. Each domain-specific agent is configured through an identity, a persona. “You are the senior seller sitting next to this person, who understands the product, the marketing, and coaches on the buyer persona, the use cases, and the value.” This is not a cosmetic tone instruction, it is how you take a horizontally intelligent model and collapse it into one specific function. LLMs are remarkably good at internalizing an identity (and their Jobs to be done) and channeling their general intelligence through it.
4. Domain experts (not Engineers) own Evals. Each agent is defined by three things: a persona, a job to be done, and the evals that judge effectiveness. An eval is fundamentally an encoding of judgment about what “good” looks like for a given task. The people closest to the business process hold that judgment better than engineers. Investing in systems and incentives that drive this behavior was a key unlock.

This stage delivered real progress. Specialists sharpened output significantly. Hallucinations were caught and suppressed. Adoption started in earnest. But a deeper limitation emerged.

Knowledge + Intelligence ≠ Strategy. The system could tell you that a major account’s usage had dropped 30% and that the technical champion had changed roles. A well-reasoned agent, drawing on all available signals, would “intelligently” recommend a defensive discount to protect the renewal. That sounds right. But the actual right answer was to accelerate an upsell, because a new enterprise tier and set of products were going to launch specifically for accounts like this one. The agent did not know any of that.

Without strategic context, the agent was not wrong in its reasoning, it was confidently wrong in its conclusion.

Stage 3: Strategic Context

Our system at this point had Knowledge and Intelligence, but no context of why the organization does what it does, or in other words Strategy.

Rather than having engineers encode strategic context secondhand, we tasked individual functions who own their part of the broader strategy to intentionally curate and maintain agent-ready context layers in systems where they already predominantly work. Product maintains what the product does, who it serves, and how it competes. Product marketing maintains the buyer personas and positioning. Field engineering maintains the enterprise solutions. Sales maintains the account plans. Each artifact is structured as a chain of reasoning: why is this a problem, why is it a problem now, and why is this the right solution. Reasoning models are remarkably good at following these chains, which means the structure of the document directly shapes the quality of the agent’s output. The system went from generically intelligent to strategically relevant.

Strategic context is not another documentation exercise. It is an institutional mechanism for making organizational intent legible to machines.

This, of course, required buy in from the leadership team and deliberate, top-down orchestration. But the value being derived after stage 2 was so much of an inflection on top of what came before, that teams did not require much convincing. The process gave them a direct stake in the quality of what the agents produce relevant to their area of expertise.

Stage 4: Experience Layer

At this point, the system was producing strategically relevant output, and the test cohorts were seeing substantial alpha over existing workflows. The natural next step was to open it up to more users across the sales organization, and more autonomy for the agents themselves, where relevant. A system that is powerful enough to be broadly useful is also powerful enough to be misused, misinterpreted, or over-trusted.

We introduced two additional constructs into what we called “the Experience Layer”:

• Access control, deterministic. Before any tokens are spent, a middleware layer checks who is (or on whose behalf the agent is) initiating the intent and whether they have access to the relevant systems. This is not probabilistic. It makes real API calls against real permissions in the source systems. If someone requests action on an account that is not in their scope — the request is rejected before the agent begins reasoning.
• Guardrails, LLM-judged. A set of narrow, single-purpose checks run in parallel against the agent’s proposed action, defined per domain-specific agent. Is the agent recommending something it absolutely should not? Is it committing to a capability that does not exist? Each guardrail does exactly one thing, and much like our anti-hallucination layer, a narrowly scoped judge with one job outperforms a broad instruction buried in a complex context. The results are consolidated and the output is modulated before anything is executed or surfaced. The guardrails are also defined by Domain Experts.

With these two constructs in place, we were able to open up the system, and realize the alpha, across the entirety of our enterprise sales organization, for both the humans operating in it and the agents acting on their behalf.

Compounding Value Loops

We have had agent families, like our Sales agent family, running in production for a few months now, and we’re expanding this agentic OS model to more parts of the organization.

This is, again, one of those things I can share from the “hindsight, not foresight” lens: The intentional, iterative, first-principles approach led us to these beautiful compounding loops that we had not “intentionally designed for”. This was learned and earned.

The building loop. Because every agent stands on the same monorepo, new agents (built with the incredible power of AI coding) inherit the pathways, integrations, and patterns already figured out by the agents that came before them. Agents of a certain complexity that would previously have taken weeks now take hours to build, and the complexity layers on. We are able to solve problems (of both east-west and north-south variety) of significantly harder cross-cutting complexity than we could have attempted even a few months ago.

The consuming loop. As value compounds, so does usage, both in frequency and depth. The frequency of queries, and the complexity of asks being made of our agents, has been phenomenal to watch. With that usage comes the ability to change manage even hard things across the organization. Enablement time collapses, which, as I have learned over the years, is generally the hardest and slowest moving part of any complex sales motion.

Each spin of the flywheel enriches the core. The core makes each spin faster.

Agent Autonomy Ladder

We think about autonomy in four stages:

1. Help. human initiates, agent assists
2. Recommend. agent watches its scope proactively, surfaces insights, proposes recommendations, human decides
3. Act. agent operates within defined boundaries, humans review exceptions
4. Own. end-to-end ownership by the agent, reporting on a regular cadence

The level of autonomy is a function of the agent’s risk profile, NOT maturity. An agent handling low-risk, high-frequency tasks can move through the ladder quickly, while an agent on a critical path may stay at the co-pilot level indefinitely.

The step up on the ladder is like granting an agent “the right to make decisions”, which has to be earned through evals and demonstrated performance over time. How well is the agent performing against its defined job and outcomes? How consistently? This model forces us to think about business value up front.

Architectural evolution for Autonomy

Additional autonomy necessitated two new architectural additions - Memory and Dreaming.

Memory is the Context that accumulates across interactions and over time. Memory attaches to the aggregate entity – in the case of the sales agent family, “the customer account”.

Dreaming is the background process that makes memory useful at scale. Agents synthesize patterns from accumulated signals, not only while responding to a human trigger, but by proactively processing what they have observed. A dreaming cycle might surface that three accounts in the same segment are showing the same early-warning pattern, or that a competitive signal on one deal is relevant to twelve others. The output feeds back into shared memory and can trigger a Recommend-level agent to surface the insight to the right person. Dreaming converts memory from a log into an intelligence layer.

The Adjacent Possible

Each architectural decision in this journey opened doors that were not visible before analyzing the impact of the previous. The monolith made decomposition possible, the monorepo made compounding possible, strategic context made autonomy possible.

We have productized the patterns that emerged from this work as Astropods, our platform for building, managing, and scaling families of agents on a shared substrate.

• Scaling becomes a platform problem, not an agent problem.
• Adoption follows when domain experts are design partners, not passengers.
• ROI becomes observable because agent outcomes tie to business impact.
• Token economics become an engineering discipline you can see and steer.

Curious what this looks like in practice? See how Astropods works, and if you’re solving this too, I’d love to compare notes.