There are two kinds of company being built right now under the banner of “AI-first.”
The first kind takes its existing product, finds places where a model can plausibly help, and wires those features in. A chat box here. A summarization button there. An autopilot feature that runs on a side queue and writes its results back into the same UI a human would have used. The product looks more modern. The org chart doesn’t change much. The system underneath is what it was a year ago, with model calls bolted on.
The second kind treats AI as a forcing function to redesign the company. Not the product. The company. It asks a different question: what would it take for a software agent to do real work here---not assist a human, but operate---under the same constraints, permissions, and accountability as a human teammate? The features it ships look similar in screenshots. The architecture underneath looks nothing alike.
We are rebuilding Trusted as the second kind of company. What follows is the architectural commitment underneath that work.
Why this matters now
The conventional wisdom in any wave of AI is that the company with the best model wins. That has never been the full story, and it is becoming less of one. Frontier models compound for everyone who can write a prompt. The model is a commodity input. What stops being commoditized is what surrounds it: the system that decides what the model sees, what it can do, what happens to the output, and how to recover when it’s wrong.
Over the next three years, the winners in markets like ours will not just have better models. They will have better operating systems: systems that let humans, software, and agents collaborate as first-class actors on shared state, under shared rules, with shared accountability. Companies that bolt AI onto their old architecture will look fast for a quarter and then hit a ceiling. The ceiling is the architecture, not the model.
Healthcare workforce is a hard place to test this thesis, which is part of why we’re testing it here. The work crosses scheduling, credentialing, matching, compliance, and conversation. The constraints are real (compliance, audit, sensitivity), the volume is high, and the cost of being wrong is concrete. If an agent-operable system works here, it generalizes.
Three principles guide how we’re building it.
Principle 1: one system, many surfaces
Business logic and workflow state should live in a shared system of record, not inside any single interface.
The opposite of this, and the default in most companies, is what we call surface-trapped state. A piece of workflow truth (this candidate is in this step, this credential is pending, this offer is open) exists on a screen. The screen knows it. Other surfaces don’t. To synchronize, someone copies it, or builds an integration that copies it, or asks a human to copy it. The same workflow ends up reimplemented in three places, slightly differently, with three slightly different ideas about what just 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.
In practice this means a clinician can move through onboarding in the app on Monday, finish a missing document over text on Tuesday, and have an Advocate help her with the last step on a call on Wednesday, and the record reflects all three as a single coherent history. The story isn’t stitched together at the end. It was always one story; we just expressed it across three surfaces.
Every conversation, one record is the concrete instance of this principle in production.
Principle 2: agents are first-class actors
Agents should not be treated as bolt-on copilots. They should be native participants in the company.
A copilot sits next to a human, suggests, and waits. An actor observes state, decides, takes action under permission, and is accountable for the result. We are building actors.
This is a design choice, not a model capability. It changes what the system has to expose. A copilot needs read access to the screen it sits next to. An actor needs to read state directly, take action through a governed interface, and be auditable by the same mechanisms a human is auditable. The work that makes this possible is in the system, not in the agent. The agent is the easy part.
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. First-class doesn’t mean autonomous. It means accountable.
In practice this means an agent can notice that a clinician is stuck on a credentialing step, request the missing document over the right channel, validate the response, advance the workflow, and escalate to a human Advocate when the document doesn’t match what was expected. The agent isn’t bolted onto a checklist. The agent is doing the work.
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
The goal is not blind autonomy---it’s delegated autonomy.
The system should handle the routine path by default and bring humans in where trust, ambiguity, judgment, or exception handling matter most. Most of the work in most workflows is repetitive and high-frequency. Most of the value is in the small percentage that isn’t.
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 between automation and humans should be explicit and well-designed. Not “the agent gave up and now the queue is full.” A clear handoff, with context, into a surface a human is already working in.
- 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.
- Success should be measured by speed, quality, cost to serve, and human leverage, not just automation rate. A system that automates 95% of the work and gets it wrong isn’t a success. A system that automates 70% and gets it right, while routing the other 30% to humans who can act on it cleanly, is.
In practice this means routine follow-up, scheduling, reminders, document collection, and status updates happen automatically. Nuanced matching decisions, sensitive conversations, and exceptions surface to a human operator with full context. The human spends her time where her judgment is the product, not on the work that doesn’t need it.
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 become real operators, not demos layered on top.
- 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.
The useful test we keep coming back to: are we building AI features on top of the company, or are we rebuilding Trusted as an agent-operable system?
The first answer is faster in a quarter. The second compounds for years.
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.
--- Lennie, Founder