Skip to content
Start a project
Start a project hello@nijora.ai

Approach

A method you can audit.

Each phase ends in something you can read and sign: a map, a test, a side-by-side comparison, a run record. Nothing moves forward on our word alone.

01 Method

The hard part isn't building an agent that works in a demo. It's getting to one your team trusts with Monday morning's queue.

We get there one workflow at a time, because that's the unit where an agent can be tested honestly: measure how the work runs today, agree in writing what “working” means, build against that test, and run beside your team before the agent acts. Each phase ends with something you can review and a decision: continue, change course, or stop. If you stop, you keep everything built so far.

Below: what each phase involves, three ways to work together, and what we'll need from your side.

02 Phases

Autonomy widens only when the evidence does.

  1. 01 · Scope

    Planned: 1–2 weeks

    Map the work. Write the test.

    We sit with the people who do the work and trace real cases through your systems: triggers, rules, exceptions, handoffs, and who decides what. We write down a baseline (volume, handling time, cycle time, exception rate) and agree with you which steps should stay human. Then we turn your past cases into the acceptance test, with the right outcome for each and the pass bar. You sign it before we write any agent code.

    Deliverables

    • Workflow map: every system, step, and handoff
    • Written baseline: volume, handling time, cycle time, exception rate
    • Two lists: automate, and keep human
    • Acceptance test and pass bar, signed by you
    • Architecture and permission design for your security review
    • Fixed-price build plan, or a written recommendation not to build

  2. 02 · Build

    Planned: 3–6 weeks

    Build against the test.

    We build in your cloud account and your repositories, released through your CI/CD, with read-only access to your systems. Connectors are scoped to the task, rules live in code, and the full test runs on every change. You see the scores every week, including every case the agent gets wrong, and why.

    Deliverables

    • Agent code, prompts, and policies in your repositories
    • Infrastructure as code for your environment
    • Test suite running in your CI
    • Weekly test scores with a review of every failure
    • Permission map: what it may read, what it may write, what it never touches
    • Draft runbook

  3. 03 · Shadow

    Planned: 2–4 weeks

    First it watches. Then it suggests.

    The agent works live cases beside your team and records what it would have done, writing nothing. We compare its decisions with your team's, case by case, and fix the disagreements. When it clears the bar, it moves to suggesting: it drafts each action, and nothing is written until a person approves. It goes live when you sign the go-live checklist.

    Deliverables

    • Shadow report: every case where the agent and your team disagreed
    • Final test results against the signed bar
    • Approval limits and escalation routes, agreed in writing
    • Go-live checklist, signed by you

  4. 04 · Operate

    Ongoing, reviewed monthly

    Then it acts, inside your limits.

    The agent acts on its own within the limits you set and stops for a person beyond them. The right to act without approval is granted one action type at a time, on evidence. We watch quality, cost, and drift, re-run the full test on every model, prompt, or system change, and review exceptions with you each month. Or your team takes over, with everything it needs to run the agent.

    Deliverables

    • Live view of volume, exceptions, and cost per case
    • Change log with test results for every release
    • Monthly review of exceptions and limits
    • Handover package on request: code, tests, runbooks, working sessions

03 Test report

You approve the test.

You sign off on the cases and the pass bar before we build. The agent ships when it passes, and the same test runs again on every prompt, model, or policy change. Go-live is a result, not a date on a plan.

Test report

Sample · illustrative data, not from a client

Invoice matching and exceptions

Built from
your own past cases, including the awkward ones
Pass bar
signed by you
Runs
on every prompt, model, or policy change

Result

We won't quote a percentage until we've measured it on your cases, against your bar.

It goes live when it passes.

Next Go-live checklist, signed by you

Pass bar

  1. Cases that need a person reach one Bar all Result Measured on your cases
  2. Cases at the expected outcome Bar signed by you Result Measured on your cases
  3. Writes outside the permission map Bar none Result Measured on your cases

Results by case type

  1. Clean invoice
    Expected
    bill entered
    Who decides
    Agent
    Result
    Measured on your cases
  2. Variance within tolerance
    Expected
    bill entered
    Who decides
    Agent
    Result
    Measured on your cases
  3. Variance over tolerance
    Expected
    to AP lead
    Who decides
    AP lead
    Result
    Measured on your cases
  4. Approved price change
    Expected
    to AP lead, clause cited
    Who decides
    AP lead
    Result
    Measured on your cases
  5. Suspected duplicate
    Expected
    flagged, to AP lead
    Who decides
    AP lead
    Result
    Measured on your cases
  6. Bank details change
    Expected
    to AP lead
    Who decides
    AP lead
    Result
    Measured on your cases
  7. Doesn't reconcile
    Expected
    supplier query drafted
    Who decides
    Agent
    Result
    Measured on your cases

Failures reviewed

  1. C-0417
    Case type
    Variance within tolerance
    Expected
    bill entered
    Got
    to AP lead
    Cause
    scanned PDF, line 3 unreadable
  2. C-1093
    Case type
    Doesn't reconcile
    Expected
    supplier query drafted
    Got
    to AP lead
    Cause
    two open POs match the same lines
  • 02 · Build Weekly test scores with a review of every failure
  • 03 · Shadow Final test results against the signed bar

Sample · illustrative data, not from a client

04 Run record

Every run, on the record.

The same four steps, in the same order, in every agent we build. Each one is recorded, so anyone you choose can open a run and read exactly what happened.

Run record tr_7f3a9c

Sample · illustrative data, not from a client

Invoice exception · Finance ops

Trigger
ap@ inbox · INV-⁠20817 from vendor V-⁠3307 · $48,212.00
Agent
ap-agent v1.4.2 · test suite passing
Models
pinned in configuration
Run
0038
Steps
09/09
Agent time
00:38.0
Human wait
03:41.0
Model cost
$0.06

Every step is recorded: inputs, sources, model and prompt version, tool calls, approvals, cost, and time.

  1. Read

    extract(​INV-⁠20817.pdf) → 14 lines · total $48,212.00

    Schema-⁠validated · no missing fields

    Source
    INV-⁠20817.pdf
    Model · prompt
    extract, prompt v1.4.2
    Approver
    none
    Cost
    $0.008
    At
    00:04.6
  2. Tool

    netsuite.​get_po(​PO-⁠77310) · netsuite.​get_receipts(​PO-⁠77310)

    Read-⁠only scope · PO total $46,980.00 · 14 of 14 lines received

    Source
    PO-⁠77310 receipts
    Model · prompt
    reason, prompt v1.4.2
    Approver
    none
    Cost
    $0.003
    At
    00:08.0
  3. Think

    Line 9: 560 units at $18.40 vs PO $16.20 → +$1,232.00 · policy AP-⁠03 limit $500 · exceeds

    The other 13 lines match the PO and the receipt.

    Source
    INV-⁠20817 · line 9 PO-⁠77310 AP-⁠03
    Model · prompt
    reason, prompt v1.4.2
    Approver
    none
    Cost
    $0.016
    At
    00:16.2
  4. Tool

    contracts.​search(​vendor=V-⁠3307, “price amendment”)

    Amendment 2, signed 2026-⁠09-⁠01, sets this SKU at $18.40 · cited: §2.1

    Source
    V-⁠3307 Amendment 2 §2.1
    Model · prompt
    reason, prompt v1.4.2
    Approver
    none
    Cost
    $0.003
    At
    00:21.3
  5. Think

    Invoice price is contractual; the PO is stale. Proposal: post the bill, request a PO update.

    Over-⁠limit variance → approval required by policy, whatever the model's confidence.

    Source
    Amendment 2 §2.1 AP-⁠03
    Model · prompt
    reason, prompt v1.4.2
    Approver
    none
    Cost
    $0.017
    At
    00:30.2
  6. Human

    Approval requested in #ap-⁠approvals → AP lead

    Attached: PO, receipts, Amendment 2 §2.1, variance calculation

    Source
    PO receipts Amendment 2 §2.1 variance calculation
    Model · prompt
    reason, prompt v1.4.2
    Approver
    AP lead requested
    Cost
    $0.002
    At
    00:31.6
  7. Human

    Approved by AP lead · 3m 41s

    Approver and decision written to the trace

    Source
    #ap-⁠approvals
    Model · prompt
    none: a person acted
    Approver
    AP lead approved
    Cost
    none
    At
    04:12.6
  8. Write

    netsuite.​create_bill(​INV-⁠20817) · netsuite.​request_po_update(​PO-⁠77310)

    Scoped writes · idempotency key inv-⁠20817 · undo: void bill until period close

    Source
    PO-⁠77310
    Model · prompt
    reason, prompt v1.4.2
    Approver
    AP lead via step 07
    Cost
    $0.008
    At
    04:18.4
  9. Done

    Done · 9 steps · 38s agent time · 3m 41s waiting on approval · $0.06 model cost

    trace tr_7f3a9c · ap-⁠agent v1.4.2 · test suite passing

    Source
    trace tr_7f3a9c
    Model · prompt
    reason, prompt v1.4.2
    Approver
    none
    Cost
    $0.003
    At
    04:19.0

Outcome

Bill posted at the contract price and a PO update requested, with the full trace on record. The AP lead made one decision, with the evidence already attached.

Run record · tr_7f3a9c

Sample · illustrative data, not from a client

05 Engagements

Ways to work together

  1. 01 Scoping

    Phases
    Scope
    Best for
    Teams with a candidate workflow who want a written answer on whether an agent fits, and what it would take.
    Includes
    • Fixed fee, agreed before we start
    • Workflow map and written baseline
    • Automate and keep-human lists
    • Acceptance test and pass bar, signed by you
    • Architecture and permission design for your security review
    • Fixed-price build plan, or a written recommendation not to build

  2. 02 Build and hand over

    Phases
    Build, Shadow; Operate: your team
    Best for
    Teams with engineers who want to own and operate the agent after launch.
    Includes
    • Build and shadow phases at a fixed price
    • Code, prompts, tests, and infrastructure in your repositories
    • Test suite running in your CI
    • Runbooks, dashboards, and alerts
    • A working session on each runbook, and support through an agreed transition period

  3. 03 Build and run

    Phases
    Build, Shadow, Operate
    Best for
    Teams that want the workflow handled without staffing agent operations in-house.
    Includes
    • Everything in Build and hand over
    • A named Nijora engineer who owns the agent in production
    • Monitoring and alerts for quality, cost, and drift
    • Full test re-run on every model, prompt, or system change
    • Monthly review of exceptions, limits, and the next workflow
    • A monthly fee agreed up front, and handover to your team whenever you choose

06 Your side

What we need from you

Checklist

  • A workflow owner who can make calls on edge cases and join a weekly review
  • Time with the people who do the work today, and a few hours a week from one of them to label cases and review shadow results
  • Past cases with known outcomes, including the messy ones, to build the acceptance test
  • A cloud account or project to deploy into, inside your platform team's guardrails
  • Read-only service accounts for each system involved, issued by your IT team Getting access to systems can be the slowest part, so we request service accounts during scoping.
  • A named approver for each checkpoint
  • A security contact for the architecture review

How much work is this for our IT and engineering teams?

Some, mostly at the start, and we'll be specific about it up front.

07 Start

Bring us the workflow with the longest queue.

We'll map it with your team, tell you plainly whether an agent should run it, and show you the test we'd hold it to.

Start a project hello@nijora.ai

An engineer reads every note and replies within two business days.