What is Zambo

2026-09-23 benchmark run

20 planned, 16 answered, 16/16 receipts, 1,239ms median.

What does the Zambo execution layer do?

Zambo sits between an AI assistant and the live systems that can answer a request. The assistant remains responsible for understanding the user's goal and choosing an appropriate action. Zambo provides the hosted tool connection, routes the call, records the observed response, and gives the host AI a stable handoff for review.

This boundary matters because a model message is not the same thing as an executed action. A model can propose a search, describe a payment, or say that a task is complete without a tool ever running. Zambo keeps the request, the execution status, the returned result, and the public receipt distinct so a reviewer can tell what happened.

The service is designed for one canonical MCP connection. A client does not need to configure a separate server for each capability. The live catalog is the authority for current tools, input fields, limits, and output shapes. Human-facing pages describe the system, while the machine-readable catalog tells an AI what is available now.

What does a verifiable execution receipt show?

A verifiable receipt identifies one selected tool call and gives another reviewer a public way to inspect the stored record. Depending on the call, it can expose the tool name, execution identifier, timestamp, status, observed result, provenance, canonical bytes, output hash, and evidence fields. The exact response remains subject to the live receipt contract.

Verification is narrower than a general promise of success. It checks that the public record is internally consistent and that its integrity material matches the recorded output. It does not create a payment confirmation, delivery confirmation, trade settlement, database write, or approval when the upstream system did not return one.

The evidence boundary should remain visible in both success and failure states. A blocked call explains that access or policy stopped execution. A provider error says that the requested system was unavailable. A pending job says that work may still be in progress. A verified read-only result says what the tool returned. These states lead to different next actions and should not be collapsed into one green label.

A receipt is also a portability feature. Someone who did not see the original chat can open the public page, identify the execution, inspect the result, and call the verifier. This supports a support handoff, a post-session audit, or a second AI that needs to continue without replaying an unsafe action.

How does Zambo preserve work across AI changes?

Continuity starts with an explicit session boundary. A host AI can pass the user's exact job, use a stable session identifier when appropriate, preserve the last verified receipt, and ask for the next safe action. The next assistant should inspect the state instead of assuming that a previous plan ran.

This design supports a practical model switch. One assistant can interpret the request, a tool call can produce a receipt, and another assistant can review the same public record. The receipt is not a transcript replacement and it does not expose private prompts by default. It is a compact execution handoff that records the fields needed for the next decision.

Continuation should be conservative. If a receipt is planned, blocked, preview-only, failed, or missing, the next AI should not repeat a consequential call automatically. It should explain the state, request the missing input, wait for the provider, or ask the person for confirmation. A stable session makes this behavior possible, but it does not turn an uncertain state into a completed one.

How should a person verify a Zambo result?

First, identify the request and the intended tool. Then inspect the returned receipt URL without relying on the original assistant's summary. Compare the receipt identifier, tool, status, timestamp, result preview, and provenance. If canonical bytes and a digest are present, check that the verifier reports the same integrity result.

Next, inspect external evidence separately. An upstream callback, read-back, settlement reference, or processor identifier can establish a specific outside state when it is real and attached to the record. An empty evidence collection is meaningful. It says that the receipt proves the recorded execution but does not establish an external outcome.

Finally, state only what the record supports. A precise conclusion might say that the named tool ran, the returned bytes passed verification, and no outside confirmation was observed. That statement is more useful than a broad claim that a business task was completed without a corresponding read-back.

1. Open the public receipt and confirm that the identifier is the expected one.
2. Read the status and observed result rather than relying on display color or summary language.
3. Call the public verifier and compare its integrity response.
4. Review provenance and external evidence as separate categories.
5. Preserve the receipt URL in the handoff and record any remaining uncertainty.

Who is Zambo for?

Zambo is useful for people who want an AI assistant to do more than generate text. Developers can connect live tools without building a separate integration for every client. Product teams can give a host AI a stable execution and continuation contract. Reviewers can inspect selected calls after a session. Researchers can compare an observed result with the public record instead of treating a transcript as primary evidence.

The free path is intentionally bounded. It lets a person test a read-only tool without creating an account, while the live service remains the source of truth for current limits and access. Paid access, when selected by the user, changes access scope. It does not change the evidence rule: a receipt still records what the system observed, and missing upstream evidence stays missing.

Privacy is part of the execution design. Public pages should not expose secrets, private prompts, raw credentials, or unnecessary ownership values. Opaque identifiers and carefully selected result fields can support verification without publishing sensitive material. A public URL makes a record easy to inspect, but it does not make every input safe to publish.

Teams adopting this pattern should begin with a read-only call, exercise a provider failure, and test the public receipt path without the original session. After that, they can add state-changing tools with an explicit read-back step. This sequence makes the evidence boundary concrete before consequential workflows depend on it.

Which sources explain the surrounding model?

Zambo's implementation is informed by public protocol and security references. The Model Context Protocol specification explains the tool connection model. The NIST AI Risk Management Framework provides risk vocabulary. RFC 8785 describes JSON canonicalization, and the OWASP Logging Cheat Sheet covers useful logging controls.

Independent public coverage is linked here for readers who want context outside the Zambo domain. These links are references, not claims that a publisher or search engine has indexed a page.

• Hashnode AER-1 article
• Paragraph execution receipt article
• Paragraph AER-1 walkthrough
• Beehiiv ZVEB article
• Cursor Directory listing