AgentStatus × Nasiko
Nasiko governs the call. TOA proves the tool still delivered.
Short complementarity brief. Nasiko is the control plane: permissions, credentials, cost, traces, kill switch. toa/0.1 is a portable signed evidence document for server delivery from scheduled probes and CI, not a tax on every tools/call. Open source. No partnership required to verify.
THE POINT
Anyone can use github.com/Carmel-Labs-Inc/toa today: toa-verify offline, or POST /api/rora/public/toa/verify. Emitting AgentStatus-signed attestations uses the product API; other emitters can sign with their own keys.
A gateway can optionally require a recent verified TOA before promoting or exposing a connector. That is a cached gate on the tool or server, not signing billions of live hops.
Talk only if useful: shared language for customers who confuse policy audit with delivery proof.
What Nasiko already ships
Strong gateway. Different question than TOA.
From Nasiko’s public product and Nasiko-Labs/nasiko: MCP Gateway merges connectors, holds credentials, enforces allow/ask/block on tools/list and tools/call, forecasts spend, emits OTel traces, and writes a policy audit trail. Connector “probe” is an initialize handshake for auth detection. Upload validation is deploy hygiene (e.g. Dockerfile), not reply grading.
On the call path, the gateway forwards the backend result straight through after permission checks. That is correct for a control plane. It is not functional delivery grading, outputSchema reply checks, or a signed portable attestation.
“Attestation” in their OCI layer means container image referrers / SBOMs, not tool-outcome evidence. Marketing “Prove” means governance ledger: what the gateway allowed or blocked.
What AgentStatus is
Gateway ≠ delivery attestation.
| Concern | Nasiko | AgentStatus / TOA |
|---|---|---|
| Tool permissions, OAuth, credential vault | ✓ | - |
| Cost, retries, kill switch, OTel traces | ✓ | - |
| Policy audit (“was this call allowed?”) | ✓ | - |
| Pass-through MCP result on the live path | ✓ | - |
| Graded delivery layers (functional / shape / …) | - | ✓ |
| Signed portable toa/0.1 + offline verify | - | ✓ |
| Continuous outside-in probes | - | ✓ |
Nasiko can add in-path soft checks later. That is a gateway-local health feature. It does not replace an independent emitter or an open verify format unless they publish one.
Independent third-party validation is two separate jobs
Reachability
Outcome
Can we talk to it?
Residential observers take the inbound path customers take — past CDN, WAF, and bot walls that treat datacenter synthetics differently. Monitoring asks: is it healthy right now? Reliability asks: does it keep working over time? “Up” means reachable from home networks, not from AWS.
Outcome verification
Outcome
Did it do the right thing?
Reachable and wrong is still broken. Scenario — did it finish the job? Compositional — do the pieces hold together? Safety — must-not-say, policy, attack probes. Stability — same ask, same story? Scores: Consistency and Drift. Not prose matching. Optional sample review is corroboration only.
Where we fit
How TOA is used (not every call).
Scheduled / CI probes.
Optional gateway gate.
Open verify anywhere.
The split
How the work divides
Your platform
- • Govern who can call which tool
- • Live path: policy + forward + trace
- • Prove access and spend decisions
Outcome
System of record
Dashboards, exports, lifecycle tools, and orchestration remain yours. We do not replace that surface.
AgentStatus
- • Grade whether the reply delivered
- • Off-path: probe, sign, verify
- • Prove delivery evidence portably
Outcome
User-side layer
Reachability (Monitoring / Reliability) from residential networks, then outcome verification once reached — Scenario, Compositional, Safety, Stability; Consistency and Drift scores. Not prose matching.
Evidence
Reviewed against public Nasiko code
Public repo design for tools/call: resolve connector → permission decide → forward → record usage/telemetry → return backend result. No functional/shape layer grades. No toa/0.1. Connector probe = initialize for auth classification.
Open TOA: github.com/Carmel-Labs-Inc/toa
What we are not claiming
We are an independent layer that runs alongside your stack.
We are not replacing Nasiko’s gateway, FinOps, or policy engine. This page is not a signed partnership. TOA does not prove the MCP server is honest; it proves a named emitter graded delivery and signed the claim. Using open TOA does not require partnering with AgentStatus.
What we'd like from this conversation
These three asks would move a pilot forward.
Language
Keep “Prove” = policy audit. Use TOA (or equivalent) when customers ask for delivery evidence.
Optional gate
Interest in requiring a recent verified toa/0.1 on connector promote?
Build vs buy
Gateway-local reply checks are easy to add. Open portable + independent continuous grade is a different surface.
Nasiko × AgentStatus.
Nasiko accounts for every agent run. TOA accounts forwhether the tool still delivered when someone needs evidence .
Contact·dulra@carmel.so·roman@carmel.so
Complementarity brief only. AgentStatus is independent and not affiliated with Nasiko. toa/0.1 is Apache-2.0.