Building an agentic system isn't building an agent. The agent that answers a call is one node in a larger system. A company where agents answer the phones, dispatch technicians and chase invoices runs hundreds of those systems at once, sharing the same data and pulling on the same people. That's an agentic enterprise, and building one is full-stack work.
Each part of that system is becoming its own discipline, and the jobs are only now getting names:
- The AI engineer designs the workflows, prompts and tools agents run on.
- The agentic data engineer models the entities, fields and relationships agents read and write, and the pipelines that keep them current.
- The agentic SRE runs the CI/CD, alerting and observability that keep agentic systems reliable at scale: the tests that gate every release, the alerts when a metric slips, and the traces that show why.
- Operators steer the work day to day through interfaces built for them.
Few companies have all of these people today. Our FDEs (forward-deployed engineers) play every role at once. They move between the canvas, the schema, the test suite and the app's code, and lose context at every switch.
The constraint on running more of a business on agents isn't intelligence. It's how fast people can build, fix and run the systems around it.
Prisma is the interaction layer for that work. It's how builders, operators and business owners work with an agentic workforce, in natural language and across every layer at once. Builders can build a new workflow end to end, or find out why one broke. Prisma changes the workflow, the data model and the interface together, and proves the change before it goes live. Business owners can ask how the workforce is doing against the outcomes they own, and get the answer with the runs behind it.
One piece of work, every layer
Take one piece of work: getting a technician to a broken heater the same day. The agent on the call is the part a customer hears. Behind it, the work runs on the platform's four building blocks:
- Agents: a workflow answers the call and books the job.
- Context: knows the customers, technicians and service areas.
- Performance: grades every call.
- Interface: gives operators a dispatch board to steer from.
Integrations connect it all to the CRM and dispatch systems the company already runs on.
The HappyRobot platform: Prisma as the intelligent interface that works across Agents, Performance, Interfaces, Integrations, and Context.
Prisma is the interaction layer that works across all these building blocks. A builder describes the work once. Prisma drafts the workflow, the Context schema and the tests that grade it, wires the integrations, and builds the dispatch board. Every piece lands as a draft, and you review the whole thing as one change.
Systems also break across layers. Say that over a weekend, heater calls start going unanswered. Nothing is down. The workflow runs exactly as written. The data matches its schema. The dashboard shows exactly what it was built to show.
Prisma starts in Performance, where the graded calls show the drop. It follows those calls into Agents and finds the step where dispatch came back empty. Then it checks Context and finds the cause: technicians are matched by city name. Whenever one city fills up, there's nobody left to send, even when a technician in the next town is closer.
The fix isn't one rule. Technicians were modeled with just a city. To match on distance, Context has to know where each technician is, what they cover and when they're working. Then the agent can read a ranked list at dispatch time: technicians who are certified, on shift and in range, ordered by drive time.
The workflow then matches on that list instead of the city name. The dispatch board shows operators who got matched, how far away they were, and why the others weren't. Prisma makes all of it as one edit, adds a test that fills up a city, runs the suites and brings you one change to approve.
Building and fixing are the same motion: a change that spans layers, made by one system that can see all of them.
The harness inside the harness
Prisma can read every layer to find out what's going on, and change every layer to act on it.
The harness inside the harness: what Prisma reads and changes in every layer.
Prisma can work across all of this safely because the platform is already a harness. A production voice agent can call Salesforce, look up a job in the dispatch system or write to Context. Each of those actions is a step in a workflow the platform versions, runs under the permissions the platform enforces, and is graded by test suites and northstars.
Prisma is a second harness running inside the first, and it borrows almost everything it needs from it.
Its action space is the platform's API. Prisma has more than a hundred tools in one registry, covering workflows, prompts, test suites, runs, Context, knowledge bases, phone numbers and integrations. Our MCP server loads the same registry, so the two surfaces can't drift apart. Prisma finds out what it can build by searching the node catalog, so a node type we ship today is one it can build with today.
Its guardrails are the platform's:
- Every tool declares whether it reads, writes or needs a person. Plan mode loads only the read tools.
- Writes land on drafts, because live versions reject edits at the platform level. It's the same check that protects every other edit.
- Deleting, buying or cancelling stops at an Accept or Deny card.
- Inside the product, a tool that publishes can't even be registered.
Its verification is the platform's. The suites and northstars that grade production agents are the ones Prisma runs before it shows you a change. It doesn't get its own definition of "working".
Its context is the platform's. Prisma reads the same runs, transcripts, grades and tables the agents produce. When it queries Context with SQL, a small evaluation model screens the query. Anything the model isn't confident about goes to a person first.
Its expertise is data. How we write prompts for voice agents is a skill. Skills load only when a task needs them. They can be personal, org-wide or global, and they're edited like any other artifact on the platform.
What Prisma owns is the loop on top:
- A step budget. A turn gets up to 50 steps. If it runs out, or hits an error it can't recover from, the tools come off and the model has to report plainly what it did and what's left.
- Compaction. Large tool outputs are compacted before the model sees them.
- An exploration subagent. Work like tracing a variable through dozens of nodes goes to a read-only subagent on a small, fast model, which sends back a summary.
- Turns that outlive the tab. Turns run server-side with no timeout, and streams are mirrored, so you can close the tab and pick up mid-turn anywhere.
- Your choice of model. The model is a per-chat choice, including on your own keys.
Building it this way means Prisma improves whenever the platform does. It also changes the conversation about trust. After we demoed Prisma to a large logistics customer, our account team summed up the room in five words: "They were amazed, also scared." That's a fair reaction to a system with this much reach. Every limit on Prisma is one the platform already enforces on its own agents, not a new set of rules invented for it.
The system is code
The biggest change we made this year was how Prisma sees a workflow.
At first, Prisma edited workflows the way you would on the canvas: add this node, connect it to that one, update this prompt, one tool call at a time. It worked, but a real workflow meant a long chain of small edits, and the model had to hold the whole graph in its head the entire time.
So we started treating the workflow as code. A compiler turns a workflow into a Python program and back, so Prisma reads and edits the whole thing as a file, the way a coding agent edits a repository. Every change is a diff. Every save is atomic and checked against the platform's node schemas. A save is rejected if someone else changed the draft in the meantime.
Once the workflow was a program, mid-sized models could build workflows that used to need the largest ones, at a fraction of the cost.
Today, Prisma's workspace holds the workflow. We're now extending it into a sandboxed session that holds the entire system in one directory:
- workflow/ holds the workflow as code, the reusable components it's built from, and the tests that gate it.
- context/ holds the Context schemas: entities, fields, relationships, and the tables agents read and write.
- interface/ holds the codebase of the app operators use: its pages, components and state.
Anatomy of a Prisma session: entry points, the sandboxed workspace, checks, and approval before publishing.
This is what makes cross-layer work tractable, whether you're building or fixing. When the workflow, the schema and the interface live in different tools owned by different people, the seams are invisible. An agent writes a field the interface never reads. A test checks a branch the schema no longer supports. In one directory, Prisma sees both sides of every seam and changes them together, the way you'd change a function and every caller in a single commit.
Verification runs against the same directory. Prisma runs the tests in workflow/ while it builds, so a change already passes by the time you see it. It opens interface/ in a browser and clicks through the app the way an operator would. Larger edits come to you as cards with the diff attached. Inside the product, approval is a required step in the pipeline, not a setting you can switch off.
Many builders already live in Claude Code or Codex, so Prisma's tools open there over MCP, with the same tool registry and the same org permissions. Without leaving the editor, a builder can:
- draft a workflow
- run its suites
- query Context
- read last night's runs
- check what a number is wired to.
Building used to be a relay between roles: scope the work, build the workflow, model the data, wire the integrations, write the tests, build the interface, set up monitoring. Context is lost at every handoff. A session that holds the whole system turns the relay into one piece of work.
That's where the speed comes from, and we optimize for it on purpose. An agentic system has real impact only once enough of the business is mapped onto it: the workflows, the entities they share, and the outcomes they're graded on. The faster each piece gets built, the sooner a company gets there.
Building is where Prisma starts. The same layer that helps you build a system today is the one that will run it on autopilot, watching it, fixing it and improving it against the goals you set.
From answering to watching
Building is half the job. The other half is running what's already live.
Ask Prisma why transfers went up on Tuesday. It reads the runs, queries Context, checks the northstar grades, and comes back with an answer and the evidence behind it.
The next step, rolling out now, is the agentic SRE's job, and it reverses the direction. When a metric slips, Prisma comes to you, in the platform, in Slack, or in your own Claude or Codex. By then it has traced the problem from the metric to the graded calls to the step that broke. It has written the fix and re-run the suites, and it waits for your approval.
That only works if Prisma stays with the problem. A fix shipped on Tuesday is proven by next week's numbers. A routing change has to hold across thousands of conversations and more than one release. So Prisma sessions are becoming long-running. They keep their goal, their history and the list of things they're watching, and they pick up where they left off when something changes.
Prisma works at three time scales: reactive, proactive and long-running.
From reports to plans
Once the work lives in one place, reports are the easy part. Plans are harder, because they need enough of a business's work modeled and measured in the same place.
Say the goal is 10% more weekly revenue. That goal touches booking, dispatch, follow-ups, collections and support. Each has its own agents, and each is tested and improved on its own. Improve them one at a time and they work against each other: faster booking does nothing if dispatch can't keep up. To plan across them, Prisma has to see every workflow that touches revenue, the entities those workflows share, and the northstars that grade each one.
That view only exists at critical mass. One workflow gives you a task. Twenty workflows over the same technicians, jobs and customers give you a model of how the business runs, and a model is something you can plan against.
Critical mass also compounds. Once technicians, jobs and service areas are mapped for dispatch, follow-ups and collections are cheaper to build, because the entities are already there. Each new workflow inherits the domain model and adds to it. Every workflow also produces graded outcomes: what was tried, for which customer, and how it scored. A platform that models the work and measures its outcomes has what it needs to improve them.
That's where reports become plans. With enough of the business modeled and graded, Prisma will break a goal into changes for each function, check every change against the goal, and keep every self-improving part of the system pointed the same way.
A business goal broken into the functions it touches, with Prisma checking every change against the goal
Where those workflows are built matters. On HappyRobot, each one adds to the same Context and the same record of graded outcomes, the model Prisma will plan against.
Today you bring Prisma something to build or something to fix. Next, Prisma brings problems to you. After that, you set the objective, and Prisma plans across every agent, test and dataset to get there.
Learn more about Prisma here.
