Ramp Built Its Harness in Six Weeks. Kill the Build-Versus-Buy Memo.

Sam Kronick published a post yesterday that will be forwarded to a lot of CTOs with the subject line "see, we should build our own." It deserves the forwarding. It is the best account of an in-house agent harness I have read, and the conclusion people are drawing from it is the wrong one.

Ramp built Laminar, its agent harness, starting around May 2026. The v1 took six weeks. Five months later every agentic product at Ramp runs on it: the support chat agent, the headless OCR agent in Bill Pay, the Ramp Inspect coding agent, and the long-horizon coworker agents that manage subagents, sandboxes, browsers, and Slack threads for hours at a time. Kronick's team got there after trying, by his list, model providers' agent SDKs, managed agent APIs, open source coding agents, popular agent frameworks, vendor solutions, and several in-house frameworks built as passion projects.

His reasons for building are specific and good. His economic claim is the one to argue with.

The short version

Sam Kronick's "Building Laminar: Ramp's Managed Agents Platform" (Ramp Engineering, October 20, 2026) explains why Ramp built its own agent harness: provider independence, a feedback loop with product teams in the same Slack that no vendor matches, and owning the observability stack, with a CTO who prints agent traces on paper. His economic claim is that coding agents made the cost of building and maintaining a platform marginal compared with vendor dependencies, and that building in-house has never been cheaper. True, and that is the column of the ledger that collapsed. The sentence that explains Laminar is his first one: Ramp products were its customers from day one. The team building the harness sat next to the teams adopting it, so landing cost nothing. The Landing Ledger says building collapsed and landing held flat, and the build-versus-buy memo compares two cells in the collapsed column. Kill it. Replace it with three lines before the decision: the first internal customer by name and where they sit, the person who reads the traces every week, and the on-call roster. Any blank means buy. My own fleet is the small version: 39 agents, 13 orphans nothing read, and a named owner as the biggest predictor of survival.

What Ramp built, in his words

The harness, as Kronick defines it, is the thing that orchestrates and manages the loop in "an LLM agent runs tools in a loop to achieve a goal." The simplest version is a while loop. Supporting a wide array of production agents turns it into fifteen responsibilities, and he lists them: secure conversation storage, session compaction, standard tool interfaces like MCP, message queuing and steering, lifecycle hooks, durable execution that survives deploys, interoperability across model providers, code sandboxes and filesystems, tool search, subagents, token-level streaming, human-in-the-loop interactions, a protocol for generative UI, multiplayer chat, and observability. Laminar took on all of it.

The early choices are worth stealing regardless of how you come down on building. Sandbox as a tool, so a session's lifetime is decoupled from any sandbox being up. Boring technology for persistence and workflow, Postgres, Temporal, and S3, because thousands of engineers know how to run them. Non-blocking by default, so a human approval or a new message does not freeze the session. Everything in the cloud on disposable workers, because the laptop-open-on-the-desk era of local agents was, in his phrase, a weird blip.

Three reasons for building. Laminar had to be model and provider agnostic, and a managed agents API from a single lab would have locked them in. The feedback loop between a platform team and product teams in the same company, same Slack, same codebases, ships faster than any vendor can. And they wanted to own observability: their CTO likes to print agent traces on paper to make the waste visible, and the off-the-shelf tools put abstractions between the team and the trace.

Then the claim. Around the time they started, coding agents had gotten good enough that the cost of building and maintaining their own platform was marginal compared to taking on one or more vendor dependencies. The v1 began as a long stream-of-consciousness prompt written on a cross-country flight. Its code was generated entirely by agents. Would they do it again? Absolutely, he says, and building in-house has never been cheaper. Then the caveat: you still need good engineers to be on call, keep the platform healthy, and figure out what product teams actually need.

The column that collapsed

Everything in that economic argument is correct, and it is an argument about the column that stopped deciding anything.

The Landing Ledger: What It Costs to Build vs What It Costs to Land has twelve rows and one finding. Build cost lives inside your org as engineer-weeks and compute, is highly legible, and is collapsing because building is a technical problem and AI is good at those. Landing cost lives on the adopter's side as switching effort, sustained attention, and habit change, is nearly invisible until it fails, and is flat, because no model changes how long it takes a person to trust a tool and rewire a week. The ratio flipped, and most organizations still budget the column that fell.

A build-versus-buy memo for an agent harness is a comparison of two cells in the build column. Engineer-weeks to build and maintain, against license fees and the cost of a vendor's roadmap not matching yours. Kronick is right that the first cell shrank. Six weeks to a v1 with the code written by agents is the proof. The memo gets more precise every quarter about a comparison that matters less every quarter.

Now read the sentence that actually explains why Laminar worked, which is the first one in the post after the introduction: "With Ramp products as Laminar customers since day 1." The platform team's customers were the product teams down the hall. No external vendor, he says, can go from feature request to shipped and production-ready in minutes; his team could, because both teams worked for the same company, sat next to each other, and shared a codebase. That is not a build advantage. That is a landing cost of close to zero, and it is the condition that decided the outcome.

Nobody forwarding this post to their CTO has that condition unless they check. A platform team formed to build "the harness" for product teams that did not ask for it, in a company where the product teams have their own vendor already, has the same six weeks of build and a landing bill Ramp never paid.

The small version of the same lesson

I have a fleet-sized example rather than a company-sized one, and the shape matches.

39 PM AI Agents Deployed: What Stuck, What Died, and Why is my audit of the agents I had appointed by April. Building them was the cheap part. Thirteen of 39 were orphans: zero references from anything outside the fleet, no page, no ritual, no other agent consuming their output. Several had run reliably for over a month producing clean output that nothing read. The single biggest predictor of an agent surviving was a named human owner, someone who notices within hours when it breaks. The single biggest predictor of death was scope drift.

That is a harness story at small scale. The build column was near zero for every one of the 39. The landing column was zero for 13 of them because nobody sat in the chair. Ramp had a person in every chair on day one, and Kronick's CTO reading printed traces is the most literal version of a named owner I have seen described.

Kill the memo

The practice to retire is the build-versus-buy memo for the agent harness. Not because its numbers are wrong. Because both of its numbers are in the column that no longer decides, and a memo that looks rigorous about the wrong column is worse than no memo, since it ends the conversation.

Killing without replacing gets reversed inside a quarter, so the replacement goes first. Three lines, written before anyone estimates engineer-weeks:

1. The first internal customer, by name, and where they sit. Not "product teams." A person, a product, and the distance between their desk and the platform team's. Ramp's answer was every agentic product in the company and the next chair. If your answer is a team alias, that is the orphan line from my audit with a bigger budget.
2. The person who reads the traces every week. Kronick's CTO does it on paper. The name goes on the line, with the day of the week. Observability you own is one of his three reasons to build, and it is only a reason if someone reads it. A session debug UI nobody opens is the thirteen orphans with a nicer interface.
3. The on-call roster. Kronick's own caveat, and the cost that does not fall when the build gets cheap. Who is paged when the harness breaks under a product that ships to customers. If the answer is the engineer who wrote the prompt on the flight, you have a passion project, which is the category Ramp built Laminar to replace.

Any line blank, you buy, whatever the engineer-weeks say. All three filled, build, and you have a landing plan before the first commit, which is the thing the memo never contained.

Ramp's own sequence agrees with the order. Ask Ramp, the support chat agent, ran on a vendor solution until it outgrew it, when the team wanted tighter integration and lower latency. Buy first, learn what you need from the vendor's constraints, then build when the vendor is the constraint rather than the budget. The memo gets written at the wrong moment. The three lines can be written at any moment, including the one where you are still on the vendor.

Where this sits

Which Model Is the Smallest Knob in the Architecture Review made the point that the harness, not the model, moves the number, and Ramp's provider-agnostic design is the same conclusion from a company that ships. Who Owns Landing? Right Now, Nobody is about the chair that is empty on most org charts. Laminar is what it looks like when the chair was full from the start.

Under Enterprise AI Agents the claim is that agent count is a vanity metric and what matters is how many agents still complete production work after ninety days. For a harness, the vanity metric is how fast you built it. Six weeks is a fine number. The number that matters is how many products run on it five months later, and Ramp's answer to that one is all of them, for a reason the memo would never have shown.

This week: if there is a build-versus-buy memo for an agent platform on your desk, do not read the numbers. Write the three lines at the top. A name and a chair, a name and a weekday, a roster. If you cannot fill them, the memo has already answered itself.

Related answer: Should you build or buy your AI agent harness?

Sources: Sam Kronick, with contributors Alexander Osmonov, Kiryl Liaushun, Vincent Capol, Alexander Shevchenko, and Alex Levinson, "Building Laminar: Ramp's Managed Agents Platform," Ramp Engineering, October 20, 2026, read in full; the six weeks, the five months, the fifteen harness responsibilities, the three reasons, and the on-call caveat are his, and I did not open the companion deep dives. Falk Gottlob, "The Landing Ledger: What It Costs to Build vs What It Costs to Land" (August 12, 2026), "39 PM AI Agents Deployed: What Stuck, What Died, and Why" (April 27, 2026), "Which Model Is the Smallest Knob in the Architecture Review" (October 19, 2026), and "Who Owns Landing? Right Now, Nobody."