PERIPLUSPAIR-ih-plus
Production Pilot
A periplus was the charted record of a first voyage. Our Pilot charts your first passage into production.
Working software on a clear path to production.
Is this for you?
- One bounded use case with a clear owner
- Founders building a first AI feature
- Teams that want evidence before a larger build
The situation
A promising demo is a question, not an answer.
Most AI projects start with a demo that works on a handful of examples. It looks convincing in a meeting. What nobody knows yet is how it behaves on real volume, real exceptions, and the systems your team uses every day.
That uncertainty is expensive. Commit to a full build too early and you pay to discover the gaps. Wait too long and the opportunity, and the budget, move elsewhere.
A pilot answers the question in between: will this workflow hold up in production conditions, and what would the full build take?
Our approach
One workflow, run the way production runs it.
We choose one bounded workflow with a clear owner, and build it against the systems and data it will meet in production. The pilot includes integrations, exception handling, and the approval points your team needs.
Before any build starts, we agree the acceptance criteria: the test, the threshold, the data it runs on, and who runs it. The pilot is measured against those criteria, and the evidence is shared with you in full.
The pilot ends with a decision, not a slide deck. You see what was accepted, what was not, and a priced route to production if the evidence supports one.
Use cases by industry
Where this service fits.
Typical applications across industries. They show where the service applies, not past client work or results.
- Insurance agency
Certificate requests prepared for account manager review
The pilot takes one request type: certificates of insurance that clients and their contractors request by email. An agent reads each request, checks the policy record in the agency management system, and drafts the certificate. An account manager approves every certificate before it is issued, and requests outside the agreed coverage types reach that person with the reason.
- Medical billing
Denied claims sorted and prepared for appeal
The pilot covers denials from one payer group, read from remittance files and the billing system. An agent groups each denial by reason code, gathers the supporting claim and visit records, and drafts the appeal packet with a cover letter. A billing specialist approves every appeal before submission, and sensitive records stay inside the boundary agreed before the build.
- Distributor
Customer purchase orders prepared for the ERP
Customer purchase orders arrive as email attachments in many layouts, and each one is keyed into the ERP by hand. In the pilot, an agent reads each order, matches items and prices against the ERP, and prepares a draft sales order. A representative approves each draft before entry, and unknown items or price differences reach that person with the mismatch shown.
- Engineering consultancy
Contractor submittals checked against project specifications
Contractor submittals must match the project specification section by section, and engineers check each one before it is returned. The pilot runs on one discipline: an agent compares each submittal with the specification and drafts review comments with references. The reviewing engineer approves, edits, or rejects every comment before the response is issued, and each edit is recorded.
- Property management
Maintenance requests triaged into draft work orders
Residents submit maintenance requests through a portal, by email, and by phone, and staff turn each one into a work order. The pilot reads each request, classifies urgency against the written policy, and drafts the work order with the right vendor. A property manager approves each work order before dispatch, and anything marked urgent goes straight to the on-call manager.
- E-commerce
Return and refund decisions prepared for approval
The pilot covers returns for one product line, where each request is checked by hand against the order and the policy. An agent reads the request, checks the order, shipment, and return policy, and drafts a decision with the refund amount. A service lead approves each refund before it reaches the payment system, and cases outside policy arrive with the order history.
- Staffing agency
Client timesheets reconciled before payroll and billing
Timesheets arrive from client sites in several formats, signed by different supervisors, and each one feeds both payroll and client billing. The pilot reads each timesheet, matches hours against placements in the applicant tracking system, and flags differences in rates, hours, or approvals. A payroll coordinator reviews every flag and approves each reconciled batch before anything reaches payroll or invoicing.
- Credit union
Member loan files checked for completeness
Member loan applications need a complete, current set of documents before an underwriter can begin the review. The pilot checks each file in the loan origination system against the checklist for one loan type, then drafts a request for any gaps. A loan officer approves every message to a member, and credit decisions stay entirely with the underwriter.
What you receive
Working software
A functional workflow or agent with representative integrations.
Evaluation and exception handling
Measured against acceptance criteria you signed, with the failure cases documented.
The charted route
What the full build needs, priced, so the next step is a decision rather than a guess.
How it works
- ScopeChoose one workflow and agree the production boundary.
- BuildImplement the agreed path and its human approval points.
- IntegrateConnect authorized systems and record operational dependencies.
- EvaluateRun representative work against the agreed acceptance tests.
- Approve or reviseYour owner reviews the evidence and decides the next step.
How success is measured
The measures your approver signs.
Each measure goes into the acceptance criteria with its test data, threshold, and the person who checks it.
- Field accuracy on real examples
- Whether the values the workflow produces match what a reviewer accepts. It is checked field by field on the agreed sample of real examples, including the awkward ones.
- Exceptions routed correctly
- Whether cases outside the boundary reach the right person with a usable reason. Reviewers check each routed case against the exception rules agreed before the build.
- Reviewer time per item
- How long a person spends reviewing and correcting each output. It is recorded throughout the pilot, so the full build is planned on observed effort rather than estimates.
- Integration reliability
- Whether reads from and writes to each connected system complete as specified. Every integration call is logged, and failures are reported system by system with their cause.
- Cost per accepted outcome
- What each accepted output costs to produce, including model and infrastructure use. It is calculated from the pilot’s run records and carries into the production estimate.
Where care is needed
What we watch, and how it is handled.
- A sample that reflects the work
- The evidence is only as useful as the sample behind it. We agree the sample with the workflow owner and include the awkward, incomplete, and unusual cases from the start.
- Access to live systems
- The pilot touches real systems, so access is agreed in writing before work begins. Each credential carries the narrowest permissions the workflow needs, and every write waits for a person’s approval.
- Scope that holds still
- New ideas arrive once people see a workflow running. We record each one for the readout and keep the pilot inside its agreed boundary, so the evidence stays comparable with the criteria.
- The exception path
- The cases a workflow cannot resolve matter as much as the ones it can. We design the exception path early, so every unresolved case reaches a named person with its reason attached.
- What carries forward
- Some pilot work is built to answer a question rather than to run for years. The readout states which parts carry into production and which parts the full build replaces.
Who does what
Your team decides. We engineer.
Your team
- Name one workflow owner who can make decisions
- Provide representative examples and access to the systems involved
- Agree the acceptance criteria before the build
- Review outputs and approve anything written to your systems
- Decide the next step from the evidence
Sophrono
- Scope the boundary and the integrations with you
- Build the workflow, its exception handling, and its approval points
- Run the agreed tests and report every criterion
- Document limitations and what the full build requires
- Price the route to production, if the evidence supports one
At the end
The decisions you make next.
The service ends with evidence and a choice. Each option is yours, and none is assumed.
Build the full system
When the evidence meets the criteria, the priced route becomes a Custom Agentic Systems build. The pilot’s tests and run records carry forward as its starting point.
Revise and re-test
When some criteria are missed, a revised pilot can run against the same tests. The readout names what to change and why, so the second run is focused.
Plan the wider system
When the pilot shows the workflow reaches more systems than expected, a System Blueprint plans the whole system before the full build begins.
Pause here
When the evidence does not support a build, you keep the findings, the test set, and the record of every correction. The decision to return stays with you.
Before we start
What to have ready.
- One workflow you would like to move off people’s desks
- A person who owns that workflow and can approve changes
- A set of real examples, including the awkward ones
- A list of the systems the workflow reads from and writes to
Related services
What “accepted” means
Measured against criteria you agree to in advance.
- The pilot runs the agreed workflow on representative data.
- Consequential actions follow the agreed human approvals.
- The evaluation reports each acceptance criterion.
- The handover identifies limitations and the go-forward decision.
Full engagement terms are finalized in a Master Services Agreement.
See a sample Acceptance CharterPlan a pilot
Tell us the workflow to pilot.
We reply with the questions that set the boundary and acceptance criteria, then a fixed price.
- A senior engineer reads every request
- A reply by email with the next step
- No obligation until scope and price are agreed
Not ready to scope this? Ask an engineer first: a free 15-minute call that names the agentic systems that could fit.
The Canon rule behind this service
Production Pilot answers to Canon V.
Where this fits
- Learn Research
- Explore free AI Workload Evaluation
- Try one workflow Diagnostic
- Plan and validate Production Pilot
- Build Custom Agentic Systems
- Improve and operate AI Stewardship
Not ready yet? Agentic Engineering Diagnostic. After this: Custom Agentic Systems or AI Stewardship.
Questions
What happens after the pilot?
The readout identifies accepted capabilities and remaining work. You choose whether to expand, revise, or retain the current scope.
How does a pilot differ from an MVP?
The pilot answers a bounded production question with an agreed evaluation. Its scope is defined around that decision.
What do we need to provide?
A workflow owner, representative examples of the work, and access to the systems involved, agreed before the build starts.
How is the price set?
The pilot is a fixed price for an agreed scope. We set it once the workflow, the systems, and the acceptance criteria are clear.
Does the pilot run on our real data?
On representative data you approve, inside the boundary we agree. Anything sensitive stays under your control, and access is agreed before work begins.
What if the pilot does not meet the criteria?
You see exactly which criteria were missed and why. That evidence is useful on its own, and the decision to revise, expand, or pause stays with you.
Can a pilot become the production system?
Often the foundations carry forward. The readout says what can be kept and what the full build must add.
Who approves what the pilot writes to our systems?
A person on your team, every time, during the pilot. Anything written to a system of record waits for that approval.
How do we choose which workflow to pilot?
Pick one with a clear owner, steady volume, and examples you can share. If several compete, an Ask an engineer call or a Diagnostic can help you choose.
What does the pilot leave behind?
The workflow as built, its test results, a record of every correction, and a written list of limitations. You also receive a priced route to production if the evidence supports one.
How does a pilot differ from the Diagnostic?
The Diagnostic is $750 for one hour of agent coding, the code delivered, an Agentic AI Blueprint, and a one-hour consultation. A pilot builds one workflow against your real systems and measures it against criteria you sign. The Diagnostic can help you choose what to pilot.
Do we need a System Blueprint before a pilot?
Not for one bounded workflow with a clear owner. When several workflows and systems are in scope, a Blueprint plans the whole system first, and the pilot can follow from it.
Does a pilot suit a founder’s first AI feature?
Yes. The pilot builds the feature against the systems it will use and measures it against criteria you agree. You see how it behaves before a larger investment.
How does the pilot relate to the free AI Workload Evaluation?
The AI Workload Evaluation looks at one workload’s AI applicability and the next steps, at no cost. A pilot goes further: it builds that workflow and measures it in production conditions.
What counts as one workflow?
One kind of work with one owner, a defined start and end, and a known set of systems. Anything outside that boundary stays manual during the pilot and is listed in the readout.
Who owns the pilot software?
Full engagement terms, including ownership, are finalized in a Master Services Agreement. The scope and the fixed price of the pilot are agreed before the build starts.
Can we change the acceptance criteria during the pilot?
The criteria are agreed before the build so the evidence stays fair. If the owner learns something that changes what matters, we agree the change in writing and note it in the readout.
Can the pilot run alongside our current process?
Yes. Your team keeps working as it does today while the pilot prepares outputs for review. Nothing depends on the pilot until its evidence is accepted.
Does a pilot need its own hardware?
The pilot runs on infrastructure agreed in the scope. If dedicated hardware is needed, it is itemized separately, and you buy and own it.