Name the core abstraction and its failure modes.
Maple AI OS Course
Capabilities, tools, MCP, and A2A edges
How an AI OS should expose tools to agents without turning every connector into a vulnerability.
Learning Objectives
What this lesson should make precise
Translate the concept into a Maple/Hermon proposal contract.
Define at least one evaluation case that can fail the model safely.
Tutorial Flow
How this lesson becomes a demo and training target
Each tutorial is written as a user education path and a model-improvement artifact. The diagram shows how the idea moves into a lab, a typed contract, an eval gate, and then a Hermon/MapleAI demo route.
Concept
Tools are capabilities
Applied Lab
Applied lab: Capabilities, tools, MCP, and A2A edges
Output Contract
capabilities, effect_type, tool_scope, composition_policy
Eval Gate
Does the answer separate model proposal from deterministic execution?
Demo Route
Maple AI OS training and public model checks
01
Tools are capabilities
A tool is not just a function call. It is a grant to observe or affect part of the world. Maple models tool access as capability descriptors with scope, effect type, budget, expiry, and audit policy.
- Read-only is different from write.
- Budget is part of authority.
- Expiry prevents stale grants.
02
MCP and A2A need OS policy
Open tool protocols are powerful because they make integration cheap. They also require a stable OS policy boundary so agents cannot chain harmless tools into harmful consequences.
- Classify each connector.
- Constrain tool composition.
- Record every external edge.
03
Compositional risk
The industrial problem is not one bad tool call. It is a chain: read data, infer a secret, write a config, notify a third party, and trigger a service. Maple evaluates the chain, not just the individual call.
- Graph the action chain.
- Check aggregate effect.
- Require commitments for consequence.
Lab
Applied lab: Capabilities, tools, MCP, and A2A edges
Design capability grants for an agent that can read GitHub issues, draft a patch plan, and open a review request, but cannot push code.
Expected result
- A typed JSON-style proposal rather than free-form advice.
- Clear authority boundaries and denied operations.
- A test or rubric that decides whether the proposal is deployable.
Evaluation
How Maple would grade this work
Rubric
- Does the answer expose assumptions instead of hiding them?
- Does the answer separate model proposal from deterministic execution?
- Does the answer produce artifacts that can be tested, reviewed, and rolled back?
Output contract
capabilities, effect_type, tool_scope, composition_policy, denied_actions, audit_receiptsUse this lesson as training direction
A strong lesson gives users a mental model and gives Hermon a sharper target for examples, probes, and demo prompts.