Pillar 3 of 5
Agents that run on models you own.
An agent is as independent as the model underneath it. We build agents on models you control, connected to your systems, with people approving consequential actions.
Why the model underneath matters
An agent carries out steps in your systems: reading records, drafting responses, updating work queues. Its behavior depends on the model it runs on.
On a model you own, that behavior changes only when your approver releases a new version. Its running costs follow the infrastructure you chose, and its data stays inside the boundary you documented.
Ownership never replaces human authority. People approve the agent's permissions, and they approve each consequential action it proposes.
This is Canon rule X: Authority stays human.
What Sophrono builds
The model is one part of the system. Business rules, tools, records, and approval points shape what an agent can do.
A permissions map
Which systems the agent can read, which it can change, and which actions wait for a person.
Connections to your records
Tools that read from and write to your systems of record, so there is one version of the truth.
Approval points
Named people approve consequential actions, with the evidence they need shown alongside each request.
A run record
Each run logs its input, context, action, human correction, outcome, cost, and time for review.
Every agent also needs an agreed way to handle exceptions. When a case falls outside its rules, the agent routes it to a person with the context attached, and that person decides.
Typical applications
Bounded workflows with a person at the decision
Typical applications by industry, not past client work or results. Each can run on an owned or a rented model.
Insurance agency
Certificate requests drafted for review
The agent reads each request, checks the policy record, and drafts the certificate. An account manager approves every certificate before it is issued.
Medical billing
Denials grouped and appeals prepared
The agent groups denials by reason and gathers the supporting records. A billing specialist approves every appeal before submission.
Distributor
Purchase orders turned into draft sales orders
The agent matches items and prices against the ERP. A representative approves each draft, and mismatches arrive with the difference shown.
Property management
Maintenance requests triaged into work orders
The agent classifies urgency against the written policy and drafts the work order. A property manager approves each one before dispatch.
E-commerce
Return requests checked against policy
The agent checks the order, shipment, and policy, then drafts a decision. A service lead approves each refund before it reaches the payment system.
Staffing agency
Timesheets reconciled before payroll
The agent matches hours against placements and flags differences. A payroll coordinator approves each batch before payroll or invoicing.
Permissions and approval boundaries
Every agent works from a written map: what it may read, what it may propose, and who decides.
| Action | What the agent may do | Who decides |
|---|---|---|
| Read records | Reads only the systems and fields in the permissions map | The workflow owner approves the map before launch |
| Prepare drafts | Drafts responses, records, and documents, held for review | A reviewer accepts, edits, or rejects each draft |
| Write to a system of record | Proposes the change and waits | A named approver confirms each write |
| Send an external message | Prepares the message and waits | A named approver releases it |
| Payments, commitments, credit decisions | Gathers the evidence only | The person your policy already authorizes |
| Change its permissions, tools, or model | Not permitted | The workflow owner, through release approval |
Reversibility and risk set the boundary. Actions that are hard to undo, reach outside the business, or commit money wait for a named person.
Each credential carries the narrowest access the workflow needs. Any attempt outside the map is refused and logged for review.
How an agent goes live
Acceptance is measured before launch. After launch, people approve consequential actions as they arise.
- DefineAgree the workflow, its owner, and its acceptance criteria.
- PermitMap the systems and actions the agent may use.
- ConnectLink tools and records, then run held-out cases.
- MeasureRecord accepted outcomes, corrections, and cost per accepted outcome.
- ApproveYour approver accepts the results and authorizes go-live.
Every accepted and rejected outcome can become an evaluation example. A person reviews each one before it enters the dataset, and the learning loop uses it to measure the next version.
A new model version reaches the agent only after it clears the held-out tests and your approver releases it.
How an agent is measured
The run record supplies the evidence. Your approver agrees the measures and thresholds before launch, and reviews them as the work changes.
Each measure is reported with the runs behind it. Where one falls short, the report names the cause and the proposed change.
- Accepted outcomesHow often reviewers accept the agent’s work without change.
- CorrectionsWhat reviewers change, grouped by type, so fixes target the right step.
- Exceptions routed correctlyWhether out-of-scope cases reach the right person with a usable reason.
- Time to decisionHow long approval requests wait for a person.
- Cost per accepted outcomeModel, infrastructure, and review effort for each accepted result.
Governance and what you keep
Permissions are written down and reviewed like any other access. Changes to what an agent may do go through the same approval as the first release.
The permissions map, agent configuration, connection code, and run records are documented for your team. Your team can inspect every run.
Full engagement terms are finalized in a Master Services Agreement, including ownership of each deliverable.
- Each permission has an owner and a reason.
- Consequential actions wait for a named person.
- Every run is logged with its outcome and any correction.
- The previous accepted version stays ready for rollback.
- Model changes need held-out tests and release approval.
Choose your starting point
Begin with the free AI Workload Evaluation for one workflow. Each route includes named approvers and measured acceptance.
Pilot one agent
Test one bounded agent workflow under real conditions, with a fixed price. People approve its actions.
Build a custom system
Design Custom Agentic Systems around your operating logic, acceptance criteria, and named approvers.
Move an existing workflow
Evaluate the workload before changing the model an agent runs on. Your approver accepts the switch.
When the agent can stay on a rented model
An agent does not need an owned model to be useful. If a rented model clears your acceptance criteria within your data rules, the agent can run on it.
The permissions, approval points, and run records are the same either way. People approve consequential actions on any model.
Not sure where to begin? The Agentic Engineering Diagnostic is $750. It includes one hour of agent coding on one workflow, the code delivered, an Agentic AI Blueprint, and one hour of consultation.
For a question first, Ask an engineer. The 15-minute call is free.
Questions
Can agents act without a person?
Only within the permissions you approve. Consequential actions wait for a named person, and every action is logged for review.
Which actions need approval?
Your team decides, based on risk and reversibility. Common examples include payments, external messages, and changes to systems of record.
Can an agent use several models?
Yes. Different steps can use different models, owned or rented, each within the documented data boundary.
What happens when the model underneath changes?
The new version is tested on held-out cases first. Your approver releases it, and the previous version stays ready for rollback.
Can we move an existing agent onto an owned model?
Often, yes. We evaluate the workload first, run the owned model on held-out cases, and your approver accepts or declines the switch.
Do agents learn from corrections?
Corrections become candidate examples. A person reviews each one before it enters the dataset, and releases still need approval.
Who can change an agent’s permissions?
The workflow owner, through the same approval as the first release. The agent cannot change its own permissions.
What happens when an approver is unavailable?
The action waits. Your team can name a delegate, and requests route to that person with the same evidence.
Can one agent approve another agent’s work?
Not for consequential actions. Those approvals come from a named person, and the run record shows who approved.
Can we switch an agent off?
Yes. The workflow owner can switch it off or narrow its permissions, and the work returns to the existing manual path.
Pillar 3 of 5