Trusted
Sign Up
Perspectives

The Agent-Ready Manifesto

How we’re rebuilding Trusted so people and software agents can work from the same records, rules, and permissions.

Lennie Founder
On this page

We’re rebuilding Trusted so software agents can take on work under the same permissions and accountability as our human teammates.

Adding a chat box or a summarization button to an existing product is relatively straightforward. Letting an agent advance a clinician’s application requires more: access to the right records, permission to act, and a way to review what happened.

A before-and-after diagram. On the left, a fragmented stack of separate product surfaces (app, internal tools, messaging, recruiter console) each with a small AI chip bolted onto its corner; arrows between them are dashed red, marking manual handoffs and duplicated workflow logic. On the right, a single system of record at the center, with humans, agents, and product surfaces all radiating in as equal participants; arrows are solid mint, indicating a permissioned and auditable action layer.

Why this matters now

Better models are becoming available to everyone. We think the more durable advantage is in the systems around them: what a model can see and do, how its output is used, and how the team recovers when it’s wrong.

Over the next three years, I expect that architecture to matter as much as model choice in markets like ours. Humans and agents need to work from the same records, follow the same rules, and leave a history that someone can inspect.

Healthcare staffing puts that architecture under pressure. Scheduling, credentialing, matching, compliance, and conversations all depend on each other. The volume is high, the information is sensitive, and mistakes affect real people.

Three principles guide how we’re building it.

Principle 1: one system, many surfaces

A central record at the middle of the canvas labeled ‘shared system of record’, with four surfaces radiating around it: the clinician app, messaging (SMS/chat), an internal operator console, and an agent. Each surface reads and writes the same underlying state through a permissioned action layer (a thin mint band around the record). A small audit trail icon sits next to the record.

Business logic and workflow state should live in a shared system of record, not inside any single interface.

Too often, a workflow’s state lives inside a particular interface: a credential is pending here, an offer is open there. Other interfaces get a copy through an integration or a person. Over time, the same workflow gets implemented in several places, each with a slightly different account of what happened.

This is fine when there is one surface. It breaks the moment a clinician moves between the app, a text message, a recruiter call, and an agent-assisted self-serve flow, and discovers that each surface believes a slightly different version of where she is.

What we’re building toward instead:

  • Workflow state lives in a canonical system of record. One representation of the candidate, the job, the credential, the assignment. Surfaces are views; they do not own truth.
  • Meaningful actions happen through a permissioned, auditable action layer. A clinician submitting an application, a recruiter sending an offer, an agent advancing a step: all flow through the same action layer, with the same permission model and the same audit trail.
  • Humans, agents, and product surfaces use the same underlying primitives. No one’s special. An agent that can advance a workflow uses the same API the recruiter UI uses. The recruiter UI uses the same API a clinician’s app uses.
  • New interfaces can be added without reimplementing core marketplace logic. When we want to put the workflow into a messaging channel, into an embedded experience on a partner site, or into a voice flow, the work is the surface. The system underneath stays the same.
  • We do not allow hidden workflow logic or state to accumulate inside individual UIs. When we catch UI-trapped state, we move it down into the system.

A clinician might start onboarding in the app on Monday, send a missing document over text on Tuesday, and finish with an Advocate on a call on Wednesday. All three interactions should update the same record as they happen.

Every conversation, one record is the concrete instance of this principle in production.

Principle 2: agents are first-class actors

Three columns showing an agent’s loop as a first-class participant. Left column: observe (agent reads from the shared state with a mint arrow). Middle column: act (agent calls a permissioned, audited tool with a mint arrow; a small lock icon marks the permission boundary). Right column: escalate (agent hands off to a human when ambiguity, trust, or judgment is required, with a small mint chevron pointing into a human silhouette). A footer reads ‘same architecture for internal and customer-facing agents.’

Agents need a defined role in the workflow, including permission to act and responsibility for what they do.

That requires direct access to workflow state, an interface that enforces permissions, and an audit trail. A model’s ability to suggest the next step doesn’t supply any of those things. We have to build them.

What we’re building toward:

  • Agents can read shared state and act through governed interfaces. Same APIs humans use. Same constraints.
  • Agents are permissioned, monitored, and auditable by default. Every action an agent takes is attributable to the agent, traceable to the prompt, and reviewable later. We wrote about the storage-layer mechanics of this in IronTrail: the moment your agents start writing to your database, callback-based audit is no longer sufficient.
  • Agent participation is designed into workflows, not layered on afterward. When we design a new flow, we ask: which actions here are agent-eligible, which are human-only, where is the handoff? Then we build the flow with those answers in the structure, not in a side queue.
  • Internal and customer-facing agents share the same architectural foundation. The agent that helps a clinician complete onboarding and the agent that helps an internal Advocate qualify a candidate are running on the same primitives. Same tool layer, same audit, same observability.
  • Humans remain responsible for oversight, system design, and exception handling. Giving an agent a role in the workflow also means defining who supervises it.

For example, an agent could notice a stalled credentialing step, request the missing document, validate the response, and advance the workflow. If the document doesn’t match what was expected, it should hand the case to a human Advocate with the context needed to resolve it.

The architectural commitment that makes this safe in production is what we call the form pattern: agents fill out the same form a human would, with the same validations, instead of writing directly to the database. The agent doesn’t need raw database access. The system gives it the same surface it gives a human. Misbehavior is bounded by what the form accepts.

Principle 3: automate the common path, escalate judgment

A two-lane diagram. The top lane shows a high-volume mint pipeline labeled ‘common path: automated’, with five sequential actions running left-to-right (intake, qualify, match, notify, advance). The bottom lane shows a lower-volume gold pipeline labeled ‘judgment path: escalated’, with three actions (ambiguity review, trust-sensitive decision, exception handling) routed to a human silhouette. A small mint chevron in the middle marks the explicit handoff point between the two lanes.

We want the system to handle routine work and bring people in when a decision needs judgment, trust, or a closer look.

What we’re building toward:

  • Repetitive, high-frequency, low-ambiguity work should be automated. Reminders, status updates, document collection, routine follow-up, the work that fills a coordinator’s inbox.
  • Decisions involving tradeoffs, trust, or novel situations should escalate to humans. Sensitive conversations, nuanced matching decisions, anything where the cost of a wrong move is concrete.
  • Handoffs need context and a clear destination. When an agent stops, the case should reach a person in a queue they already use, with enough information to continue.
  • Actions should be reversible, inspectable, and measurable. Anything the system does, a human can see, evaluate, and (where appropriate) undo. The system is not a black box.
  • Measure speed, quality, cost to serve, and the work people can get done. Automating 95% of a workflow means little if the results are wrong. Automating 70% well, with a clear handoff for the other 30%, is more useful.

The clinician-side version of this same principle is Auto Apply: the clinician opts into a preference set once, and the system applies on her behalf when a match clears the bar, with a human Advocate escalated where her judgment changes the outcome.

What this architecture enables

If we get this right:

  • We can add new channels (messaging, voice, embedded partner surfaces) without fragmenting the product.
  • Agents can complete permitted steps in a workflow.
  • Humans spend less time on coordination and more time on judgment.
  • Product and operations teams can iterate faster, because they’re working in one system instead of synchronizing across many.
  • The product becomes more scalable, more personalized, and lower cost to serve over time.

We’ll judge this work by whether people and agents can complete those workflows reliably, and whether people have more time for the decisions that need them.

We’ve been writing about specific instances of this architecture in production: Every Open Shift for the thesis, the form pattern for how agents take action safely, GLaDOS for the shared LLM layer that every agent rides on, IronTrail for storage-layer audit. The principles in this post are the architectural commitments those pieces add up to.

More Perspectives