October 14, 2026
Over the last year and a half I have been working side by side with Postman’s CTO, Ankit Sobti, on the agent platform we use to deploy all of our internal agents as we transform the company to be AI-native. This is a follow-up to his post on the Agentic OS we built, which covers the business need that led us here, an architectural overview, and the technical precedent that shaped our thinking. In this article, I will discuss the problem space surrounding building agents for enterprise, in particular for non-verifiable qualitative domains (not coding/math), our approach to solving them, and the open problems that remain. I hope this serves as a useful guide for high-agency engineers or engineering leaders hoping to steer such an effort.
Context
I came to Postman after working on a startup. There is a stereotype that technical founders would rather code their way through problems than talk to customers. Unfortunately, these stereotypes can occasionally be true. With no salespeople or budget, I too chased the dream of a product that grew itself through scrappy LLM-augmented outreach tools, but learned the hard way that no amount of automated go-to-market (GTM) can grow something that doesn’t have a market. In coming to Postman, I actively sought the opposite problem. Postman had already reached 40 million users through product-led growth. So, a primary objective was to just convert an increasing subset of those existing users into paying customers by delivering real enterprise value, and to keep shaping the product around what they told us about their new AI needs.
I helped found our forward deployed engineering (FDE) team, wrote its first playbook and shipped our first major deployments, which led to significant million-dollar expansions in annual recurring revenue. Although we were able to get to a great outcome with these individual customers, the process behind it could not scale. We relied on our executives’ intuition to pick the right accounts. We could only read so much of the calls, emails, product telemetry and support tickets on each one, and even what we did read missed context that lived only in the account team’s heads, outside our systems of record. Filling the gaps meant more discovery on the customer’s schedule, and nothing we learned reached the sellers, so even a problem we had already solved came back to us.
What we needed was a GTM machine that relentlessly compounds. Everything we know about a customer would live in our systems of record, and the machine would read all of it and tell our people which accounts to approach, with what, and what to ask the core product team or FDE to change in our product. Anything our team had built once would become something sellers could sell on their own, which would leave FDE free for the last mile of novel engineering. Every time our people acted on what the machine told them, the result would become new data, so its next recommendation would be better informed. It also had to be cheap enough to run on every account every week, and keep working as the models and the data underneath it changed.
So I tried automated go-to-market again. This time I was armed with the luxury of a product that had already found its market. My startup-background-induced naiveté about accelerating a field that has always run on intuition and relationships at enterprise scale was shielded by our developer tool founders, who shared my rose-tinted view that we should be AI-pilled and apply agentic thinking outside software. Having learned my lesson, I wanted the best of both people and AI, and that came down to a maxim.
Abstract
Fig. 1: A ring of people forms the only boundary a customer touches, and inside it a dense green network of analysis.
Maximally human on external communication. Maximally AI on internal analysis. That should be the self-improvement loop of any enterprise.
Maximally human on external communication. Maximally AI on internal analysis. That should be the self-improvement loop of any enterprise.
Let’s start with the external half. As much as possible, every customer should feel that their problem was heard by a person who cares, and that the solution was built for their use case. Our largest accounts have a median of 45 stakeholders named on their deals, and the median relationship has run about three years, so keeping those relationships strong is one of the best uses of our people’s time. AI can handle the quick things, like a support answer at midnight or an automated onboarding flow. But an AI avatar on a sales call, or a bulk-generated cold email that blindly guesses at a customer’s problems, cheapens the brand, and that is not what being AI-pilled means.
The internal half is a great place to be AI-pilled. You want decisions made at a velocity, throughput, and accuracy no individual can mentally accomplish, and the reason is that it is biologically impossible. Research on working memory finds that we can actively juggle only about four chunks (meaningfully grouped pieces of information) at once (Cowan, 2001), where in our case 1 call would roughly be 1 chunk. Even at one large account for one year, there can be hundreds of calls and thousands of emails. To make matters worse, the highest leverage insights are often thematic across accounts and it can get up to {calls, emails, telemetry, support, docs, etc.} × years × accounts. This is terabytes of data that no person can hold while trying to draw the highest leverage line of reasoning across all of these data points.
Fig. 2: Each cell is one account’s year of records. The green path links the data points the agent reasons across on its way to an answer, and the small box shows how little of it one person can hold at once.
Take a seller who wants to reach out to each of the customers in their book of accounts that would benefit from something we launched recently. Doing it well means reading up on each account, and with a couple hundred accounts each there is not enough time in the week. Timing matters here, because the frontier moves quickly and features go stale. An agent can go through every account for them, pull out what it finds that matters for each one, and bring the strategies our best sellers have already succeeded with to all of them. The seller can then write to every customer and tailor the message to the right stakeholder with exactly how it would benefit them.
As we grow more confident in the strategies our best sellers use, we can hand more of that work to the agent to run autonomously. The questions sellers ask over and over become skills, the skills they run every week become scheduled reports, and eventually the agent keeps its own memory of each account, asking the questions it deems important to meeting our KPIs.
To climb toward an agent that does more on its own, we can take a page from how software handled layers of abstraction. Engineers once wrote machine instructions by hand, until an assembler took over that translation. Compilers then let them write in languages people could read, like C, and object-oriented languages like Java let them bundle data with the code that works on it, so they could build large systems out of reusable parts. This ladder worked because every rung had both generation and verification. Generation meant a tool could produce the work at the new level. Verification meant engineers could check that it was right. A compiler gives the same output every time it gets the same code and refuses to build code with whole classes of mistakes, so engineers could trust each rung and build the next one on top of it.
Qualitative domains had neither automated generation nor verification before AI. Enterprise GTM is one such qualitative domain. The answers to questions like “What is the optimal strategy to sell customer X on product feature Y?” are open-ended and have no true right answer. Previously, you could not automatically generate an answer for the next move on an account without a human Account Executive in the loop. Now, an agent with tools generates an answer based on the subset of data it finds during its execution time. However, it is still hard to know whether the agent reached the optimal subset given the global corpus. Did it find that one call where they discussed their new AI strategy? Did it look at the one data point in the product telemetry where it shows they actually were leveraging your new feature but in an unconventional way? Verification remains an open problem. We have not solved it, but every approach that has worked for us starts the same way, by breaking it into smaller checkable pieces.
Fig. 3: Each braced software rung pairs with a check, from the hardware up to tests, while the rungs above the line, like the next move on an account, stop short unchecked.
I decided the generation half was promising enough to build on, and started with a GTM coaching agent that answers our sellers’ questions about our customers from the thousands of calls we have recorded with them. Like any conventional agent, it began as a model, a system prompt defining its persona, and tools that return data, all running in a harness that accepts a question and loops until it has an answer. From there it grew into an accelerated agent deployment platform that now enables agents to be quickly spun up for any end user across the company. Since late May, nearly 400 employees have used them, from sellers and executives to product managers, marketers and engineers, through Slack, the web, MCP and the command line, both for questions they ask and for proactive reports and alerts that come to them. The coaching agents alone reach nearly all of our sellers, about 220 people a month, and have been asked almost 10,000 questions. Monthly questions grew 76% from July to September, with 80% retention, and a strong power law in usage with 1 in 10 having asked more than 100.
Spinning agents up quickly and serving answers turned out to be the easy part of that platform. Aside from verification to ensure we were improving the agent over time, a significant hurdle was getting the right people working on the parts of the agent they were best suited to. Every team has its own goals, incentives, definition of a good answer and view on who should see which data, and each is right about its own, so we were never going to write their agents for them from the outside. What makes the platform work is that each team writes only the part it understands, and everything else lives in a shared substrate we maintain for them. The agent becomes a configuration of a shared thing instead of a new thing, so every improvement to the substrate lands on every agent standing on it. That is what lets the GTM machine compound.
Fig. 4: Four team agents differ in shape and in their prompt, tools, data, guardrails and access settings, yet all stand on one shared substrate that improves beneath them.
1. Everybody Builds Their Own Agent
Agent building inside enterprises has reached a fervor we have not seen before, because anyone who can write instructions and connect a data source can now build an agent. Even within a single team, several people build agents that share a function, end users, and data sources. Nobody wants their agent to just sit on their laptop, so they rush to serve it to the others. Unfortunately, everyone else has the same idea and serves theirs back. Every one of these efforts stands up its own pipeline over the same data, so each new agent leaves another copy of your customer records somewhere with less oversight than the last, and those pipelines go ungoverned the moment access expires or a dependency changes, which is when the agent starts answering confidently out of data that stopped updating weeks ago. There are two common attempts at solving this, and both appear to work at first.
The first attempt is to let the domain team or individual build it themselves. Our sellers did, through Claude Desktop, wiring up connectors by hand. That gets you running in an afternoon, and the person doing it understands their own workflow better than any platform team will. What you cannot do is scale it to an entire team and globally steer it. Outcomes varied wildly from one seller to the next, because each seller wrote different instructions and connected a different set of sources, so two sellers asking about the same account could get answers drawn from dramatically different data. When an executive wanted every agent working the new sales play, there was nowhere to put the play. It lived in a deck and the agents lived in individual sessions, so none of them ever saw it, and the machine we set out to build depends on exactly that kind of shared context. The same gap shows up in how they read data at face value. If the customer said the product was too expensive, the agent told the seller to offer a discount. That is rarely the right answer, since any customer of any product in any industry could ask for a discount, whether or not the product serves them. What the seller actually needs might be a nudge to re-qualify the champion, or to re-anchor on the outcome the customer is buying. Those are strategies our senior sellers and executives have worked out, and a personal agent has no way to receive them.
Fig. 5: Six sellers have each wired a different mix of sources into their agent, and the new play sits in a deck none of the agents can reach.
The second attempt is to hand the work to a forward deployed or applied AI team. These are skilled software and systems engineers who have learned to work with AI. Put them together as a small team and they can handcraft one agent per internal use case. That solves steering, because those engineers own the single copy of each agent deployed to a team, so one change reaches everyone using it. What it does not solve is anything after the first version. Each agent is bespoke, so there is nobody to hand it back to, and it stays with the people who built it. Every one shipped becomes something somebody keeps alive, and making the same patch to each agent they shipped is not the highest leverage use of a capable engineer’s time.
Fig. 6: Engineers add the same new play to four bespoke agents one at a time, and the fourth, negotiation prep, is still waiting for its copy.
What became obvious once a few of these sat side by side is that they were variations of the same bounded list. An agent is a system prompt, a subset of the tools and data sources you have already provisioned, a model and a budget for how long it is allowed to think, an execution horizon that says whether it answers when asked or runs on a schedule, a set of guardrails, and a rule about who may invoke it and which fields it is allowed to read. And this list can always be expanded as you uncover new primitives you want to bring to all of your agents.
What we need is for the platform to be configurable so that each of the relevant parties in the company can write the component of the agent that pertains to them and leave the rest to the others. Access control, the hard deterministic rules governing who can reach which agent and which data fields, is best controlled by IT. The system prompt is best written by the domain team, since they know their own workflow and what they want the agent to do on their behalf. The guardrails, the soft steering markdowns that keep the agent away from the poor behavior you only learn about by deploying it, are best written by the manager. Instead of one of these teams writing every component, or an outside engineering team guessing at all of them, each component gets decided by the people closest to it. The agent platform team can then just work on improving the overall substrate.
Fig. 7: Each bear built by a single team fails in its own way, and the combined bear takes access control, prompt, runtime and guardrails from the team closest to each.
2. Deploying Every Agent from a Monorepo
In order to have catch-alls for functionality the platform did not support out of the box, we let agent developers write custom code on top of the agent they were serving. That code turned out to be the signal we needed. When our engineers found themselves writing patches with the same shape for the third or fourth time, the shape got promoted: it became a field any agent could declare in its manifest, with no code at all.
Every agent is written to a single monorepo that deploys when a PR merges. An agent is a directory. Everything specific to that agent lives inside it. Two folders that every agent shares sit outside it: the globally provisioned tool set, which each manifest names a subset of, and the guardrails, which name the agents they apply to. The appendix shows an example of each of these pieces.
Fig. 8: Apart from its SKILL.md, every setting on deal-coach-pro is a choice from a fixed set, including 52 of the 54 tools and 32 of the 45 guardrails.
When it comes time for deployment, we wanted a mechanism that enabled agent developers to quickly deploy their agent without taking down a shared substrate. Astropods, our agent deployment and governance platform, made this very convenient. The shape of it is ordinary Docker. Every agent builds from the same Dockerfile with the same build context, the whole backend, so COPY . . bakes every skill into the image. Each agent then carries a manifest, a short YAML file that names that Dockerfile and declares the environment variables its container needs. One of those variables is the name of the skill directory to serve. The adapter reads it at boot and serves only that one, which means the codebase is the artifact and the variable is the pointer: every pod runs the same tree with a different path lit up inside it.
Fig. 9: SKILL_NAME lights up the deal-coach/ directory and the shared files, tools and guardrails it names, and every gray entry ships in the same image without being loaded at runtime.
3. Getting Long-Horizon Results at Runtime Speed
One thing held across all of our agents: the longer we let a run go, the more tokens we let it burn, and the more data we gave it access to, the better it performed. This is perhaps a microcosm of Richard Sutton’s Bitter Lesson, which holds that massive computation dwarfs last-mile algorithmic iteration. The constraint with building runtime agents like the above is that users expect an answer inside a reasonable window, about two minutes.
Fig. 10: Inside the two-minute window hand tuning gives the better answer, but past the crossover more tokens and longer runs keep improving it long after tuning has flattened.
You can give them the option to configure a job that runs much longer, ten minutes or more, and we did, but that carries its own set of problems. One, if everyone starts launching computationally intensive jobs at will, token spend goes out of control. Two, you stop your users from getting deeply nested in a workflow and reaching the higher order insight. When responses come back quickly they keep going down the rabbit hole, and your overall usage of the tool grows exponentially. This can also be read through Jevons paradox, which says that the cheaper you make something the more of it people use, except that inside an enterprise the thing your employees are trying to conserve is often not cost but their own time. So if they believe it is saving them real time, and more of it is at their fingertips, they will use it more, which raises their overall AI consumption and drives your transformation.
We needed to find a way of providing the benefits of longer running jobs while making the runtime inference fast and cheap. We need to find a way for an AI agent to figure out which pieces of information are the highest leverage for an account and refresh those as new information comes in every week. “Highest leverage” is a vague term that is specific to your company’s needs so to filter for this we would need another probabilistic agent steered by prompts to filter the high volume of incoming information. I will discuss two approaches I took here: a harness that allows an agent to recursively in parallel spawn sub agents so that it can better research an account, and the second being Anthropic’s first party dreaming primitive. The former was hand-rolled before the release of the latter but both have since proven to have their benefits.
Fig. 11: Streams of data arrive all week, and one agent, set by its model, prompt, tools and token budget, keeps the few items that fill the account document.
The first in-house method is what we call the research pipeline and it runs once a week for 8 hours. Each account research process begins with a deterministic set of API calls that pulls everything new since last week’s run from each of our data APIs into a shared store. This includes the Salesforce record, its opportunities, its account plan and its contact roles, along with transcripts from every Zoom call, product telemetry and support tickets. From here, in batches of 4, 24 sub agents are spawned that use this store as a seed to decide what threads they would like to further investigate. What they are looking for is fixed by the sub agent in advance and it is informed by what they see in the seed, what agents from previous batches already returned, and core pillars the account team cares about (renewal risk, expansion path, stakeholder map, implementation blockers, recent customer sentiment). Each of these sub agents reasons over the tool calls it is making until they find what they were looking for or the token budget runs out.
The path each one takes through the data closely resembles a graph traversal, because at every turn the agent can move vertically, deeper into the same source, or horizontally, across to a different one. For example, it might be reading a chunk of a Zoom call where the customer says a feature no longer works for them, and go vertical, back through earlier calls to see whether they turned it off, or horizontal, out to the product telemetry to see whether they are using it at all. It ends up making a combination of horizontal and vertical turns, which resembles an A* search, except that the heuristic is the model’s probabilistic evaluation of whether a tool call will yield alpha, whereas A* would use a deterministic function. At the end, every agent returns its findings to a more intelligent, large context model that synthesizes the data points and writes a detailed account dossier. This dossier is stored in a relational database and also embedded into a vector database. It is available as a tool at runtime and the agent is told to prefer it in the tool definition and system prompt since if it contains the answer to the question being asked then further tokens don’t need to be burned querying the raw data source.
Fig. 12: Researching sub agents walk the seeded sources, stepping deeper or across at each turn, and their findings feed one synthesis that writes the dossier.
While the research pipeline is our best attempt at giving agents the highest leverage insights at runtime, Anthropic released Dreaming as a primitive for curating an agent’s memory directly. Rolling your own keeps the cultivated memory model-agnostic. Using a black-box dreaming API makes sense for the opposite reason. The model provider is the one most likely to know what harness curates information so that their own model recalls it the way you want at runtime.
Given that, I set up a second pipeline in parallel, on Dreams. To understand Anthropic’s Dreaming you have to start with their managed Memory Stores.
Fig. 13: The SQL query returns one Acme row and the embedding search four onboarding chunks, but the security review chunk holding the answer falls outside both.
Fig. 14: The agent lists all files, greps for rollout down to three, then reads timeline.md, which points it to security-lead.md, a file the grep never matched.
