I.
Scope, by inheritance.
The agent doesn’t need to be told what process it owns or which step it’s in. It’s a node attached to a process node. Move the process; the agent moves with it.
Agents in your operating model
Agents need an operating model too.
Drop an agent into the graph and it inherits its scope. Which process it owns. Which decisions it can make autonomously. Where it must escalate. Who its peers are. Below: an invoice-processing agent, in flight, on a Tuesday morning.
Fig. — A walk-through of agents traversing the org graph: scope inherited from the process node, escalation routed via the people graph, audit written back to the model.
// trace · ap-classifier-v3 · invoice #INV-2026-04-28-091
● completed · 4h 47m
Tuesday, 09:14 — vendor: Acme
t+0:00
event.received(channel='ap-inbox')
Invoice arrived from acme.co — PDF, 2 pages, $8,420.00
graphprocess · invoice-to-pay · step 1
t+0:01
agent.classify(type, vendor, urgency)
Type → services · Vendor → Acme (known, tier-2) · Urgency → standard
graphagent · ap-classifier-v3
t+0:03
extract(line_items, totals, tax)
9 line items · subtotal $7,650 · VAT 770 · total $8,420 — confidence 98%
t+0:08
match(po_number) → PO #4471
PO match score 96% · variance within tolerance · GL acct 6210-services
graphprocess · po-matching
t+0:09
policy.check(amount=$8,420 < threshold $10k)
Within autonomous-approval band. No second signature required.
graphpolicy · ap.autonomous-band
t+0:11
route(approver) → Priya N., Controller, EMEA
Approver resolved from org graph. Backup: Marcus T. (delegate). Out-of-office: none.
graphperson · priya-nair · controller-emea
t+0:14
await.approval()
Notified via Slack #ap-approvals + email. SLA 24h.
t+4:46
approval.received(by='priya-nair')
Approved with note: ‘standard quarterly retainer — ok’
t+4:46
post(erp='workday-fin', batch=2026-04-28-091)
Posted to GL. Cash-flow forecast updated. Vendor portal pinged.
graphsystem · workday-fin
t+4:47
audit.commit(trail, sox_mapped=true)
Immutable audit record written. Signed by agent + approver.
graphcontrol · sox-302
// agent.context
ap-classifier-v3
invoice processing · finance-ops
owned byfinance-ops · accounts-payable
governsinvoice-to-pay · steps 2 → 4 of 7
autonomousup to $10,000 · tier-1 & tier-2 vendors
escalatesamount > $10k · tier-3 vendor · variance > 5%
reports tocontroller, emea (priya nair)
kpicycle time · cost-per-invoice · accuracy
auditiso 27001 · sox 302 · gdpr
30-day performance
847
invoices99.2%
accuracy4h11m
median cycle
What you see
The agent is a node in the graph. Its scope, peers, and escalation path are inherited — not configured per agent.
Where the agent sits in your graph.
§ Graph sliceSTRATEGY
Reduce DSO 8→5 days
OKR · finance
PROCESS
invoice-to-pay
7 steps · iso-mapped
STEP
classify + match
steps 2 → 4
POLICY
autonomous ≤ $10k
governs
AGENT
ap-classifier-v3
OWNS
PERSON
Priya Nair
escalates to
SYSTEM
workday-fin
posts to
What the org graph gives an agent.
§ The pointII.
Decision rights, by policy.
What it can decide alone, what it must escalate, who it must escalate to — read from the same policy nodes that humans read. One source of truth for both.
III.
Audit, by construction.
Every action is a write to the graph: which node fired, on what input, with what outcome. The audit trail isn’t a separate log — it’s the graph’s history.
Bring your first agent
Drop an agent into the graph.
Invoice processing is the easy one. We’ve also dropped agents into onboarding triage, policy compliance, customer-issue routing, capacity planning. The pattern is the same: connect to a process node, inherit the rest.
Invoice processing
$10k autonomous · ERP-integratedOnboarding triage
New-hire checklist · routingPolicy compliance
Process drift · automatic flagCustomer-issue routing
Severity → owner · SLA-bound