This deck is a conceptual, provider-neutral model of agent orchestration.
It shows visible inputs and tool exchanges, not private model reasoning, actual
system prompts, or a live trace of a particular product. No model or tool is called.
Context means the inputs available for a particular model turn, not all model
knowledge, every repository file, or an unlimited persistent memory.
The named context window morphs into the next slide using Marp's native
View Transition support. Other boundaries demonstrate cover, reveal, slide, and glow.
Source: https://github.com/marp-team/marp-cli/blob/v4.5.1/docs/bespoke-transitions/README.md
These groups are illustrative, not a universal instruction hierarchy.
The host determines instruction priority, permission checks, and which project
instructions are applicable. User prompts can themselves contain instructions.
Reading a file or receiving a tool result does not promote its content into a
higher-priority instruction. The host still enforces permissions independently
of whether an instruction describes an action.
The stable frame moves from the cover into this larger composition through the
shared, per-slide-unique ctx-window view-transition-name.
The progressive disclosure sequence follows the Agent Skills specification:
name and description are available for discovery; the full SKILL.md body is
loaded when activated; supporting references, assets, or scripts are used only
when required. Individual hosts may make different selection decisions.
This slide's debugging recipe and the other skill names are fictional examples.
A skill can include procedures and scripts, but it is not the same thing as a
callable tool and does not by itself override the host's permission system.
Source: https://agentskills.io/specification#progressive-disclosure
This is a logical orchestration diagram, not a requirement to use MCP or a
particular API. Many hosts can expose local and remote tools without MCP.
The MCP specification provides a concrete example of tool metadata/schema,
tools/call requests, results, and a host's responsibility to validate operations.
A tool can return errors as well as successes. Tool descriptions do not prove
that an operation was executed, and a result need not be included in full.
Source: https://modelcontextprotocol.io/specification/2025-11-25/server/tools
Run starts the illustrative sequence; there is no autoplay on this interactive
slide. Step moves between complete, explainable snapshots. Choose Build a feature
or Debug a failure to change the prompt, selected skill, requested tool, and result.
The feature example reads a fictional search component. The debugging example
receives a fictional failed-test observation. Completing the animation means
the next turn has its inputs; it does not mean either coding task was fixed.
The stage timing and content are illustrative, not measured agent telemetry.
Pause, replay, speed, visibility suspension, and reduced motion are local to the
audience window. Presenter/next-slide previews remain static. Print always shows
the authored feature example, even if the browser was midway through debugging.
This is a design principle, not a claim that every host compacts context in this
way, that summarization is lossless, or that compaction always improves results.
Hosts differ in context limits, retrieval, caching, truncation, and persistence.
Preserve governing instructions, relevant facts, source references, and unresolved
questions. Do not silently discard constraints or turn untrusted output into rules.
The bar sizes are a visual metaphor, not counts, percentages, or benchmark data.
PDF deliberately retains labeled before and after compositions; no animation frame
or client-side diagram rendering is required to understand the takeaway.
All diagrams and animation code in this deck are original.