How we work
From your workflow to a system you can run.
We connect your systems, build the agent and its tools, and test the complete workflow before rollout. You review working software and the evidence behind each release.
Follow a buildSource records → tool contracts → release evidence
01 Map the workflow
Connect the records behind the decision.
We work backward from the action your team needs to take. For each source, we identify the record IDs, access rules, refresh method, and owner. That becomes the integration design.
Here, the invoice arrives as a document. The purchase order and receipt come from NetSuite. We link them by supplier, order, and line item so every recommendation can point to its evidence.
Your process owner brings sample records and checks the source map, exception rules, and decisions that should stay with a person.
Workflow map, source inventory, and integration scope.
Invoice document
INV-1042 · page 1What is the supplier asking us to pay?
- System
- Email attachment / Google Drive
- Record
- 100 units × $84.20 = $8,420
- Integration
- Parse the document into a validated invoice schema; retain the page reference.
- Control
- Document ID + source revision
02 Define the boundaries
Give the agent tools. Define their limits.
The model extracts invoice fields and explains the mismatch. Application code checks the schema, calculates the variance, and enforces the approval policy.
We define each tool’s inputs, outputs, and permissions. A proposal becomes a bill-creation command only after an authorized reviewer approves that exact revision. Changed evidence requires a new review.
You approve the permitted actions, review thresholds, and what the system must do when information is missing or contradictory.
Tool schemas, approval rules, and failure-handling design.
BillProposalWrite blocked- invoice_id
- INV-1042
- amount_cents
- 842000
- approved_revision
- null
- operation_key
- Not issued
The agent can prepare the exception and evidence. Without a matching, authorized approval, the application rejects the ERP write.
03 Build and evaluate
Test the decision.
Test the failure.
Coding agents work from the agreed architecture, schemas, and repository context. Engineers review their changes and test the integrations. Model evaluations check extraction and evidence; code tests check permissions, arithmetic, and state changes.
We turn your examples and edge cases into a versioned evaluation set. Failed cases include execution traces to help locate the problem and test the fix.
$8,420 invoice against an $8,100 order; all 100 units received.
Route the exception to AP review.
Code calculates the $320 / 3.95% variance. The example policy requires review above $100 or 2%.
- Parse document
- Match order
- Check policy
- Queue review
Model evaluation
Extract the correct amount and cite the invoice and order lines.
Code assertions
variance_cents === 32000
route === "human_review"Illustrative acceptance criteria, not live test results. Model changes and integration changes rerun the relevant checks before release.
Your team reviews workflow examples with us. Together we set acceptance criteria for quality, latency, cost, and the consequences of an incorrect action.
Reviewed code, repeatable tests, evaluation cases, and release evidence.
04 Deploy and operate
Expand the scope as the evidence supports it.
We start with a controlled rollout: observe without writes, enable an agreed pilot, then extend access when release criteria are met. The approval policy stays in force at every stage.
Each operation carries an identity through its execution trace. If a write times out, the system checks the original operation before attempting another submission. Monitoring tracks failed tools, queue age, latency, and cost per task.
You approve the pilot scope and operating owner. We agree who responds to failures, pauses writes, and authorizes the next release.
Deployment configuration, monitoring, recovery procedures, and an operating runbook.
Observe without changing records.
- Scope
- Representative invoices in a read-only workflow
- Write access
- Disabled
- Evidence
- Compare proposed actions with the decisions your team actually makes.
- Recovery
- Log discrepancies and refine the evaluation set before enabling writes.
What stays with your team
The system—and the context to change it.
Code ownership, licensing, deployment accounts, and support responsibilities are agreed before implementation.
- Source & architecture
- Reviewed code, integration contracts, and the decisions behind the design.
- Evaluation assets
- Versioned examples, expected behavior, and checks to run when the system changes.
- Deployment & recovery
- Environment configuration, access ownership, rollback steps, and incident procedures.
Talk to an engineer
Let’s scope your next build.
Bring a workflow, a product brief, or an AI system that needs to ship.