A Capsule is a function with luggage, fingerprints, and a very strict border agent.
1. Motivation
Pickling a function can preserve bytes without preserving an inspectable public identity, input schema, docstring, restore policy, or trust decision. Importing a module path is readable but fails when the consumer does not share the original checkout. ACapsule records callable identity, signature, schemas, docstring, dependencies, restore layers, capabilities, trust flags, and integrity fingerprints. It can behave like the original function now and restore it later under an explicit policy.
Restoring a Capsule executes Python code. The metadata makes that boundary reviewable; it does not make untrusted code safe.
2. Capture and Call a Function
Capsule accepts a callable directly and preserves function-like metadata. Capsule.from_func(...) is the equivalent explicit constructor.
It also works as a decorator:
3. Understand Restore Layers
The default capture considers source and import-path layers. A trusted-localcloudpickle layer is optional and disabled by default.
4. Inspect and Verify Before Running
verify() checks stored source and binary payloads against the fingerprints in the same manifest without executing the callable. That is a record-integrity check, not a comparison with today’s live source and not a code-safety proof.
to_str("json"), to_str("yaml"), to_str("source"), and to_str("docstring") expose reviewable forms. Capsule.from_str(...) restores JSON or YAML manifests.
5. Let an Application Workspace Own Toolkit Capsules
Concrete Toolkit persistence stores thesys-toolkit row and every referenced sys-capsule row in one explicit application workspace:
Capsule.register() and Capsule.load() remain advanced Context-private administration over the configured Capsule registry. Use them when a Capsule genuinely exists outside an application Toolkit, and pass matching resolver/config authority when isolation matters.
6. Load and Run a Standalone Capsule
register() defaults to overwrite=False. load() verifies stored checksums and restores lazily. Capsule.list(...) inspects stored rows; Capsule.delete(...) tombstones by default.
For ordinary Toolkit code, prefer toolkit.register(ws=...) so Capsule and Toolkit rows share the explicit application workspace.
7. Use Capsules Behind Tools
Tool is a function-like view over one execution Capsule plus an optional serializer Capsule. Toolkit.add(...) accepts a Tool, Capsule, or plain callable and normalizes all three to the same contract.
Agent and MCP calls remain keyword-oriented even though local Tools and Capsules can behave like their wrapped functions.
8. Keep the Trust Boundary Explicit
- Treat installed module artifacts and Capsule rows like source repositories.
- Keep
include_cloudpickle=Falseunless a reviewed local callable requires it. - Review input schemas before exposing a Tool to an agent.
- Scope MCP profiles to the minimum tools and entities required.
- Use explicit workspaces and Contexts so executable state does not drift into ambient authority.
- Use tombstones or new versions for intentional lifecycle changes; immutable revision history is not a universal application migration system.
Summary
- Capsules capture callable behavior with inspectable restore layers and fingerprints.
- Application workspaces own Capsules referenced by persisted Toolkits.
- Integrity is not safety; executable payloads remain trusted code.

