Build vs buy for agentic applications

Build vs buy for agentic applications is the decision about who builds and maintains the foundation under every application: identity, authorization, approvals, audit, durable execution, context, and release lifecycle. The agent itself is the small part. The foundation is where most of the cost, risk, and time goes, and whether it is reused decides what later applications cost.

What are you actually deciding?

You are not deciding who writes the agent. Frameworks make agents easy, and every option ends with someone configuring prompts and tools. You are deciding who owns the layer below the waterline, which is invisible when it works and security-critical when it does not.

A demo needs a model, a prompt, a few tools, and a chat window. A production application needs 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. That is the gap between a three-week prototype and a nine-month estimate, described in Component build vs platform.

What is in the bill of materials for a custom-built agentic application?

Twelve components recur. Each is a solvable engineering problem with good building blocks available. The cost is that each one must be designed, integrated, security reviewed, and maintained, and most are rebuilt or adapted for every application unless a team deliberately makes them shared.

Two items deserve emphasis. Authorization is a model, not a library: a library evaluates rules, but someone still has to define what a reviewer in one business unit may see and do, and keep it aligned with the permissions people already have. Audit only works if it covers every door; a record that captures the chat path but not the scheduled job leaves the gap an incident will find.

What does a reference DIY architecture look like?

A common custom stack is LangGraph for agents, Temporal for durable processes, a cloud identity provider, a relationship-based authorization service, a vector database, and a React front end. Every piece is mature. The work is in the seams between them, and in the parts none of them provides.

A typical layout:

1. React front end with pages for requests, reviews, and approvals, authenticated through the enterprise identity provider (for example Entra ID).
2. API layer that validates the user's token, calls the authorization service (for example OpenFGA) for each operation, and writes an audit record.
3. Temporal workflows for each long-running process. A workflow starts agent work as activities, waits on a signal for an approval, and resumes after a restart.
4. LangGraph agents inside those activities, with tools that call internal systems. LangGraph's own persistence and interrupts handle short-lived agent state and pauses.
5. Vector database and ingestion pipeline for policies and procedures, with metadata filters to approximate document permissions.
6. Secrets manager and service identities so tools reach systems without credentials in prompts.
7. Observability through OpenTelemetry traces and an evaluation harness for regression tests.

The seams are where the design effort goes. Both LangGraph and Temporal can persist state and pause for a person, so the team must decide which one owns a pending approval and make sure the other cannot resume around it. The authorization check in the API layer must also run when a Temporal workflow or an agent tool calls the same operation without a user present, or the scheduled path bypasses the rules. Document permissions in the vector store must track changes in the source systems. And the audit record must have one shape whether the call came from a page, a chat, a schedule, or another agent. None of this is exotic. All of it is the team's to build, test, and maintain.

How do you estimate the cost of building versus buying?

Estimate both options as three terms over the number of applications you expect, not the first one. Put engineer-months, not dollars, on each line of the bill of materials, then apply your own loaded cost. Nothing below is a benchmark; it is a structure for your own estimate.

For a build over N applications and Y years:

• Foundation build (one time), F. Sum the engineer-months for every component in the table that will be shared, plus the security review. Mark each line "we have it," "we will build it," or "we will skip it." Every skipped line is a known risk, not a saving.
• Foundation maintenance, M per year. Upgrades to frameworks and runtimes, security patches, on-call, audit support, and the platform team's time answering other teams. A useful starting assumption is a meaningful fraction of the build, every year, for as long as the applications run.
• Per-application cost, A. Process logic, tools, prompts, front end, testing, and the share of the foundation that is not reused. Write it as A = P + (1 − r) × F, where P is the process-specific work and r is the fraction of the foundation genuinely reused (0 to 1).

Total build cost is roughly F + (M × Y) + (N × A) + run costs (models, compute, storage).

For a platform, the same structure applies with different values: an adoption cost (SSO, access profiles, approval policies, loading knowledge, connecting data), a subscription or consumption term per year, and a per-application cost that is mostly P, because r is close to 1 by design. Run costs remain.

Three questions usually decide the comparison. How large is N realistically over three years? What value of r will your team achieve in practice, given that each project is under pressure to ship? And how many months of delay can the first application absorb while the foundation is built?

When is building the right choice?

Building is right when owning the foundation is strategic or when the application is small enough that the foundation is small too. These cases are real, and a platform vendor should say so.

• Agent infrastructure is your product. If you sell an agent platform, the foundation is your differentiation and you should own it.
• A funded platform team already exists. Some enterprises run an internal platform group with the mandate, security partnership, and multi-year funding to build shared services. If it has capacity, it can build this layer once for everyone.
• One narrow lane. A single deterministic process with one caller, no approvals, and no external side effects can be built directly on a framework with a durable executor underneath.
• Constraints no vendor meets. Some environments impose hosting, certification, or integration requirements that no available platform satisfies.

When is buying the right choice?

Buying is right when the enterprise expects several applications, needs the first one quickly, and would rather spend its engineers on the process than on the foundation. It is also right when the security and audit bar is high and the team would otherwise discover the missing parts at the first incident.

• More than a few applications are planned, across functions, with shared users and shared knowledge.
• People must review and approve agent work, and approvals depend on amounts, parties, or record types.
• Auditors or regulators will ask who acted, under what authority, with whose approval, under which version of the rules.
• The team that would build the foundation is the same team that should be building applications.

What does a hybrid approach look like?

Most large enterprises end up hybrid. They buy the shared foundation and build what is specific to them on top of it: process configuration, front ends, and domain services with their own logic and storage. Existing agents keep running and call into the platform under its rules.

The hybrid works when the platform exposes clean seams: an API for configuration and runs, MCP so external agents act as the user, a way to run client code next to the platform with platform-handled authentication, and outputs that land in the systems people already use. Durable execution engines such as Temporal and managed runtimes such as LangSmith Deployment, AgentCore, or Foundry Agent Service remain useful underneath or beside the platform. Ask any vendor, including Pyrana, to show those seams working.

Pyrana vs custom-built

Pyrana is the foundation from the table above, built once and shared by every application. Identity, authorization in layers (tenant, App membership, access profile, scope entitlement, approval lane, with OpenFGA for relationship checks), the eight-step admission gate with the audit record written before dispatch, tool approval policies with frozen invocations and named lanes, durable workflows on Temporal workers, versioned resources, cortIQ for governed context, an eval pipeline, and the push, activate, and rollback lifecycle are part of the platform. An application is one App configuration plus the frontend experience.

What a client still builds is what a custom build would also need: the process configuration, the frontend experience, and any domain service with its own logic, which runs as an extension in the same cluster, reachable only through the platform. With clean data available, an application typically takes about a week to stand up, and the frontend is the main effort. A first engagement, including SSO, access profiles, the approval policy, and loading the policy library into cortIQ, runs about six weeks. Pricing is enterprise pricing through contact; the platform is hosted as SaaS on a dedicated private tenant or deployed into the client's own infrastructure for large enterprises.

On lock-in, the application stays legible. It is one YAML document plus the agents, workflows, and tool sources it binds; agent configuration is plain language, workflows are declarative, Context Units can be exported, and tools built for the platform can in many cases be called from outside it. If you are still deciding which layer to start from, framework vs runtime vs platform lays out what each provides.