Skip to content
Pyrana
For AI and data leaders
Build vs. buy
Agent infrastructure

Component build vs. platform: what you actually have to build below the waterline

The agent demo is a model, a prompt, and a few tools. Production is authorization, tenancy, durable execution, approval policy, idempotent effects, audit, secrets, and versioned configuration. Here is what each one costs to build, and how we handle it.

Eric Tarnowski
September 9, 2026
8 min read

Your team built an agent in three weeks. A model, a system prompt, four tools, a chat window. It handled the demo cases and the steering committee asked when it could go live. Then the engineering estimate came back: nine months, four more people, and a security review that nobody has scheduled.

I have been on both sides of that estimate. The demo was honest. The estimate was also honest. The gap between them is the part of the system nobody puts in the demo because it is invisible when it works.

The demo is above the waterline

An agent demo shows three things: a model, a prompt, and some tools. Every framework makes those three things easy. That is the point of a framework.

Production needs a fourth thing that does not fit on a slide. It needs the machinery that decides whether this call, from this caller, on this data, with this approval, may run at all, and that writes down what happened either way. I think of that as the part below the waterline. There are eight pieces. I will name them so you can check your own estimate against the list.

Fine-grained authorization that people and agents share. The agent needs to act as itself, or on behalf of a person, against the same permission model your people already have. If the agent has a separate model, you now maintain two and reconcile them after every org change.

Tenant isolation. If the application serves more than one business unit, client, or legal entity, the data separation has to hold at the database layer, not in the prompt.

Durable execution. A process that waits three days for a signature cannot start over when a pod restarts. Something has to checkpoint state and resume from it.

Human approval as policy. A per-tool "requires approval" flag does not know that 41,800 USD is above the 25,000 USD threshold, that finance and treasury both need to sign, or that one approver left the finance group yesterday.

Idempotent external effects. A retry after a timeout must not pay the vendor twice, create the ticket twice, or send the email twice.

Audit. A record of every call, written before the call runs, that names the caller, the authority, the data, the policy version, and the outcome. Written after the fact, it is a log. Written before, it is evidence.

Secrets. Connector credentials that the agent never sees and the prompt never contains.

Versioned configuration. Which version of the app, the prompt, the tools, and the policy governed a call made on a Tuesday in March, and a way to roll back to the previous one.

None of these is exotic. Each is a few weeks of work for a good team, plus a security review, plus maintenance forever. The problem is arithmetic. Eight pieces, each one security-critical, each one rebuilt per project by a team whose job was the agent.

The industry keeps rediscovering the list

I do not have to argue this from first principles. The vendors have been showing their work.

Amazon's AgentCore pricing page lists thirteen separately priced components: Runtime, Browser, Code Interpreter, Web Search, Gateway, Policy, Identity, Memory, Observability, Evaluations, Optimization, Agent Registry, and Payments (AWS, Amazon Bedrock AgentCore Pricing, September 2026). That list is a fair inventory of the waterline. It is also thirteen bills. In July 2026 AWS made AgentCore Harness generally available to reassemble those pieces into one managed agent, "with no orchestration code and no container to build" (AWS, AgentCore release notes, July 2026). Read that as a hyperscaler concluding that shipping the components was not enough.

OpenAI went the other direction. Agent Builder, the visual canvas in AgentKit, launched in October 2025. On June 3, 2026 OpenAI told developers it was deprecating Agent Builder and the Evals platform, with both shutting down on November 30, 2026, and pointed builders to the code-first Agents SDK (OpenAI, API deprecations, June 2026). Eight months. Whatever else that tells you, a canvas for wiring agents together was not where the hard problem lived.

Durability is its own cottage industry. Temporal's integration with the OpenAI Agents SDK reached general availability on March 23, 2026, wrapping agent loops as workflows and tool calls as retriable activities for what Temporal calls "crash-proof execution" (Temporal, March 2026). Inngest, DBOS, and Restate sell the same promise. They exist because the frameworks do not carry it.

Retool, which sells app-building tools, was blunt about it in June. AI code generators and vibe-coding tools "don't have a comprehensive data permission model, a vetted and secure resource access layer, or detailed audit logs," so "the governance risk lands entirely on the enterprise" (Retool, June 17, 2026).

And Forrester, in its June 2026 report on the state of agentic AI, explained why the governance document you already wrote will not close the gap: "a policy document can't control an autonomous, tool-invoking system" (Forrester, June 3, 2026). Policy has to be enforced in the path of the call, as code, or it is a poster.

When you should build it anyway

I run a platform company, so discount this section as you see fit. There are still three cases where building the layer yourself is the right call.

You are a platform company. If agent infrastructure is your product, the waterline is your moat and you should own every inch of it.

You have a platform team already. Some enterprises run a real internal platform group with the mandate, the security partnership, and multi-year funding to build shared services. If that group exists and has capacity, it can build this. Be honest about whether it has capacity.

You need exactly one lane. A single deterministic workflow with no human approvals, no external side effects, and one caller can be built directly on a framework with a durable executor underneath. The waterline is short when the application is small. The trouble starts with the second application, the first approval, and the first incident.

If none of those three describes you, you are about to fund eight security-critical subsystems as a side effect of wanting one agent.

How we handle it

At Pyrana the layer below the waterline is built once, generically, and every application is a composition on top of it. Your domain code stays in your repository. Here is how each of the eight lands, with its status.

  • Authorization. Access profiles correlate what a caller may do with which slice of data, as one grant. Enforcement is layered: tenant isolation with row-level security, OpenFGA relationship checks, App profiles and scopes, operation policy, resource authorization, approval policy. People and agents pass the same checks, and a child call can never exceed its parent's authority. Live.
  • Tenant isolation. Row-level security in Postgres, with OpenFGA above it. Unauthorized items are absent from results, never "denied," so nobody learns a record exists by being refused. Live.
  • Durable execution. The workflow lane runs on Temporal. A process that waits three days for a signature resumes where it stopped. Live.
  • Approval. A policy over typed arguments: thresholds, membership, existence, compound rules. Above threshold the invocation, arguments, scope, and evidence are frozen; each named approval lane gets its own obligation; reviewer eligibility is checked at decision time; the frozen invocation is revalidated before dispatch. Built, enabled per App.
  • Idempotent effects. Admission claims an idempotency identity before dispatch, so a retry reuses the receipt. Extension effects carry deterministic idempotency keys. An ambiguous provider outcome goes to reconciliation rather than a blind retry. Admission is built; effects are live; reconciliation ships with the approval policy.
  • Audit. Every call through any of the five doors (App UI, chat, API, MCP, schedules and events) passes one admission check and produces one AppExecution record, written before dispatch. Built; cutover is a per-installation step.
  • Secrets. Extensions never hold external credentials. Pyrana performs outbound actions with platform-held credentials and owns retry and audit. Live, in production in two client extensions.
  • Versioned configuration. An App is configuration compiled into an immutable, content-digested version, activated by moving one pointer, rolled back the same way. Live.

I want to be precise about status because this reader will ask. The App lifecycle, the authorization model, the extension contract, the execution lanes, and cortIQ are live. Per-invocation admission with the unified AppExecution record, and approval as policy with frozen invocations, are built and merged; they are switched on per installation and per App rather than on by default everywhere. We say "the platform does" for those. We do not say GA.

The extension model is the part I would look at hardest if I were you, because it is where your code meets ours. A client's domain logic runs as a sidecar in the client's own repository, with its own database and its own transactions. It publishes a content-digested manifest of its routes, tools, and effects. Every call into it carries a short-lived delegated token bound to the tenant, the actor chain, the App, and the scope. It returns typed effects rather than performing external actions itself.

One of our clients runs an IT project-management extension this way. A manager drags a card, a colleague asks chat to move a project, and a nightly workflow advances the stale ones. All three resolve to the same operation, pass the same admission, and write to the same domain transaction inside the client's extension. When a project needs to sync to an external system, the extension asks for that as an effect, and Pyrana performs it with credentials the extension never sees.

The scorecard

If you are deciding between building and adopting, score both options on these questions. Answer each with "we have it," "we will build it," or "we will skip it," and put an engineer-month number next to every "build."

  1. Can an agent act as itself, and on behalf of a person, under the same permission model our people use?
  2. Does a child call ever get more authority than its parent?
  3. Where is tenant separation enforced, and can a prompt bypass it?
  4. What happens to a three-day approval when a process restarts?
  5. Is approval a flag on the tool or a policy over the arguments?
  6. What does a retry after a provider timeout do?
  7. Is the audit record written before or after the call runs?
  8. Can I name the exact configuration version that governed a call last March, and roll back to it?

If the build column has more than three "we will skip it" entries, the build column describes a demo.

Next week

Take the eight items to the team that produced the nine-month estimate and ask them to tag each line of the estimate with one of the eight, or with "the agent." If most of the estimate is below the waterline, you know where the money goes. Then take the scorecard to any vendor you are evaluating, including us, and ask for answers in mechanisms. A vendor who answers with an architecture diagram and no record of a refused call has not built the layer either.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo