A Working Model of the Prompt Stack

The repository, the product contract, and the agent action loop now fit into one question: what can a reader responsibly infer when a captured prompt describes an AI product? This checkpoint connects those ideas into a practical prompt-stack model, then uses it to separate declared behavior from observed behavior and prompt rules from host-side enforcement.

The model is useful because a prompt capture rarely presents its architecture as one neat diagram. It may begin with identity, continue through style and safety, move into tools and memory, and end with output syntax or API guidance. A second file may isolate only a reminder, a connector, or a coding harness. The reader has to reconstruct the relationships. The goal is not to memorize every section. It is to understand which responsibility each layer owns and what crosses its boundary.

A prompt stack is a chain of authority

Start at the product surface. A web chat application, search assistant, coding agent, connector-rich workspace, and API layer place different demands on the model. The surface determines the user’s likely goal, the available operations, and the consequences of a wrong response. The repository’s classification work matters here because it prevents a reader from applying an agent interpretation to an app prompt or treating a dynamic fragment as the whole product.

The role-and-relationship layer follows. It tells the assistant what kind of participant it is: a tutor, collaborator, researcher, coding agent, or adaptive general assistant. That role shapes which actions count as helpful. A coding agent is expected to reason about a workspace and report actions. A search-oriented assistant is expected to manage currentness and sources. A general assistant may prioritize explanation and conversational continuity. The role does not create the underlying capability, but it gives the capability a purpose.

State and context determine what information is available to that role. The captures distinguish current conversation, stored preferences, past-chat retrieval, workspace context, connector data, and user-background information. These channels are not interchangeable. A workspace file can be edited, a preference can guide tone, a past conversation can supply continuity, and a search result can supply current evidence. The prompt may describe when each channel is relevant, while the host system owns storage and access.

Safety and intellectual-property rules cut across the other layers. They can change whether a request is answered, searched, visualized, or passed to a tool. A conditional reminder can add context-specific guidance to a base prompt. A visual-output policy can allow an educational diagram while restricting harmful or infringing imagery. A copyright rule can permit a summary while limiting direct reproduction. Safety is therefore a decision boundary in the stack, not a detached closing paragraph.

Tool routing and permission convert the role into action. A tool schema describes an interface, but routing rules decide when the interface fits. A connector may require user choice. A file edit may require authorization. A search may be appropriate only when information can have changed. A tool result may be temporary evidence rather than persistent memory.