01 between systems
Work that lives in nobody’s system
The order arrives by e-mail, WhatsApp or a portal; the price list is a spreadsheet; the stock is in the ERP. The work is the join between them, and it is done by hand.
implementation
part 01 of 03
One workflow, into production. And kept there.
We implement and operate one bounded, recurring workflow inside your company: clear limits, a result measured in your own systems, and a loop that keeps improving it.
§01 the problem
01 / 05
The cost is in the work between systems.
An incomplete order, someone retyping it, an exception stopping the queue, and nobody measuring any of it.
02 exceptions
One exception stops the queue
A missing field, a customer over their credit, a special price. Each one waits for a person, and the queue waits with it.
03 not measured
Nobody knows what it costs
Minutes per case, cases reopened, the ones that went wrong quietly. Without a baseline, no automation can prove that it helped.
capability is not use
The models reach far more than companies run
The Anthropic Institute’s economic scenarios (September 2026) calibrate today’s use of AI at about 10% of the tasks the models can already reach. Reach belongs to the labs. Use, the gain realised and how much runs unattended move one workflow at a time. That is where an implementation works, at any level of reach.
from zero, or from what exists
Greenfield or rescue, the same job
Some workflows start from nothing. Many start from an agent that already exists and never reached production: a stalled pilot, a bought platform, an automation that grew. Both get the same treatment: a bounded scope, tests from real cases, a supervised launch, and a decision at the end.
Already have agents →Korinek, Jones, Sacher, Cotter and McCrory, “Economic Scenarios for Transformative AI”, Anthropic Institute WP 2026-02, September 2026 (the views are the authors’). Today’s use is a calibration in the paper, not a measurement of your company.
§01.1
Reach belongs to the labs. Use belongs to a deployment.
§02 the flow
02 / 05
From the order that arrives to the record accepted in the ERP.
One order, seven steps, two places where a person decides. Illustrative: order intake at a distributor.
scene 04 one place to pass through
one action · one line
- 01 intakeThe order arrives by e-mail, WhatsApp or portal. The agent reads it and opens a case: one record that will hold everything that happens to this order.
- 02 structureItems, quantities, customer, delivery terms, read into a structured order. What cannot be read is marked unknown, never guessed.
- 03 validationChecked against the catalogue, the price list and the customer’s history. What is missing is asked for.
- 04 credit and special priceA person decides. The case is held; the approval covers the real action and the real arguments, not a button that says “approved”.
- 05 stock reservationReserved in the ERP through the control plane: owner, rule and amount on the line. Over the limit, it is held, not written.
- 06 the recordThe order is written to the ERP once. A refusal is written too, with the rule and the owner on it.
- 07 the outcomeDays later, owno reads back what happened: shipped, corrected, reopened, disputed. Finished is not correct until then.
Illustrative flow. If your process is different (shipping documents, a B2B quote, an administrative file), the same spine applies: intake, structure, validation, the decisions people keep, the write, the outcome read back.
§03 the deployment
03 / 05
A bounded implementation, with decisions along the way.
The delivery clock starts when data and access exist. Timing in weeks, exact by scope.
step 1 readiness study2–3 weeks
Baseline, scope, access, a costed plan
A study you can inspect, valuable even when the answer is “do not automate”.
- Volume, cost, human minutes and exceptions today
- Concrete scope: one channel, one catalogue, what stays manual
- Access map: systems, APIs, test environments, who authorises
- Deliverables, timing from access, price
Decision at the end: implement, narrow, or stop.
step 2 implement and launch8–12 weeks after access
One bounded workflow, to production under supervision
Adapters, executor, tests, runbook, supervised launch. The ERP, the CRM and the automation tool stay.
- Adapters to your systems, inside the agreed access
- The executor, with authority set by the workflow owner
- Acceptance tests from ten to twenty real cases, approved by you
- Runbook: exceptions, on-call, who decides what
- Supervised launch and the first release evidence
Decision at the end: accept the production scope.
step 3 operate and improvemonthly
Included cases, a service window, a change budget
Operation, exceptions and contracted support. Human review priced and counted, never implied. The six numbers are on the improvement page.
- Cases included per month, service window, response times
- Review by your specialist, counted in hours
- Changes shipped through the release gate
- Monthly evidence: the six numbers, on the original workload
- Inference at cost, on your own keys
Decision at the end: renew or resize on measured value.
§03.1
The clock starts when access exists, not when the contract is signed.
§04 responsibilities
04 / 05
Clear responsibilities on both sides.
Every class of exception needs a name before the launch, not after the first one.
owno
What we own
- Implementation and connectors
- Operation, exceptions and contracted support
- Acceptance tests, runbook, the improvement cycle
- The case record, from intake to outcome
you
What stays yours
- Policy, authority and the rules
- Access to systems and test environments
- Who says what is correct
- Operational acceptance and the release decision
together
What we decide jointly
- The baseline and the method of comparison
- Incident decisions
- Expansion to the next scope, priced on its own
§05 already have agents?
05 / 05
Already have agents running? We start from them.
The hard cases arrive after the demo: incomplete context, rules that change, tools that fail. The problem is rarely the model.
01 what blocks wide use
Integration, supervision, evaluation or data
A failure map from the agent’s own cases says which one. Most rescues are not a model change; they are a missing join, an unpriced review, or a test that never existed.
02 execution joined to the outcome
What the agent did, joined to the ERP, the CRM, the finance system
A trace shows the first event. The case holds all of them: accepted, corrected, reopened, disputed. Until the join exists, “working” is a guess.
03 every change with a test
Hard cases preserved, versions compared
The cases that broke it become the acceptance set. A prompt, tool or model change ships only when it passes them; critical failures are counted apart, so one serious one never disappears into an average.
04 in your environment
Inside the agreed access, without changing platform
The agent stays where it runs. owno works inside the access you grant, with the record in your warehouse, and leaves release evidence you can hand to whoever asks.
Recovery is priced as its own offer: a known workflow, an authorised intervention, a failure map, an acceptance set, a targeted correction, and the evidence of the release. What you buy →
the first step
OWNO-WEB-1.2 · 2026-09-09
Start with one decision you can inspect.
A readiness study of two to three weeks: baseline, concrete scope, access map, costed plan, and a go or no-go with the numbers on the table.
owno.ai · São Paulo