Internet of Agents: Incident Network
Coordinate investigation and an approved repair across three independent hosts. Verify the service after the change.
On this page
A customer can investigate a failure without acquiring the provider’s authority to repair it. Chio carries selected telemetry and a bounded proposal between independent hosts; the provider approves the exact change and executes it through its own kernel.
Take the deployment the rest of the docs build. Basalt’s buying agent starts receiving 403 responses from pricing.larkfield.example for one region. Basalt can show Larkfield what it sees, and it can never change Larkfield’s edge. Halden, which Larkfield retains for engineering work, diagnoses the failure from what Basalt disclosed. Larkfield decides, and Mara Okafor approves removing exactly one regional rule at one configuration version. Larkfield’s kernel executes the change, and a separate Basalt health check decides whether the incident is over.
Run the incident application
The federated incident response application runs this pattern with three hosts in separate processes, each with its own kernel. Start with the failing regional rule, approve its removal, then inspect the separate customer health check. Withhold approval to keep the rule in place, or leave the backend broken to see why an applied change does not establish resolution.
| Participant | Owns | Retained result |
|---|---|---|
Customer (Basalt) | Selected telemetry and health checks | The disclosed investigation payload and observed service status |
Specialist (Halden) | Diagnosis under investigation authority | A bounded remediation proposal |
Provider (Larkfield) | Approval and the actual service change | The approved request and provider-signed execution receipt |
Keep the run directory to associate the proposal, approval, execution, and post-change observation. The application guide shows the source at each boundary and explains how to replace the repair adapter with one of your own operational controls.
What each boundary holds
- Disclosure stays with the customer. Basalt’s telemetry tool returns the service, region, and observed status. Raw request logs stay in Basalt’s process, and the specialist’s retained record shows they never left.
- Diagnosis carries no repair authority. Halden returns a proposal and holds no remediation grant on Larkfield’s edge. An investigation grant cannot widen into a change.
- Approval binds one request. Larkfield prepares a governed intent from the current service, rule, and configuration digest, and Mara’s approval covers that intent alone. A request for a wider repair, or one made with revoked authority, stops at its own check and produces no effect.
- Resolution is observed, never assumed. Removing the rule changes the response; a separate backend failure can still keep the service down. The incident closes only when Basalt’s own governed health check returns 200.
Architecture
The refusals worth running
Each failure path ends in a different place, and the retained run records which one:
| Try | Result |
|---|---|
Execute before Mara approves | Refused at Larkfield’s kernel; the edge rule stays active and the incident stays open. |
Request a wider repair than the approval names | Refused; the approval binds the exact rule and configuration version. |
Use authority Larkfield has revoked | Refused; no remediation effect occurs. |
Approve, but leave the backend broken | The change applies, the health check still fails, and the incident stays unresolved. |
Across real organizations
The application runs three hosts on one machine, each with its own kernel and keys. Between real organizations, the same exchange runs over a federation relationship: Larkfield pins Basalt’s and Halden’s kernel keys, the treaty names which action classes cross, and each receipt is verified against the signer that owns the effect. Bootstrap Federated Trust sets up the relationship, and Two-Org Worked Example shows how the receipt pair reads across both kernels.