Goal: understand which component generates text, which component can act, which service bills you, and where permissions are granted.
Prerequisites: none beyond the mandatory Data classification and AI tools module.
Execution context: reading and discussion only. Do not enter project data or credentials into any service while completing this page.
The Stack#
Products often bundle several layers, but the layers still have different responsibilities:
| Component | Examples | Purpose |
|---|---|---|
| Model | Claude, GPT, GLM | Produces a response from the supplied context |
| Model provider | Anthropic, OpenAI, a hosted inference provider | Operates an endpoint that serves a model |
| Gateway | OpenRouter | Offers one API across providers, routing, billing, and limits |
| Agent harness/runtime | GitHub Copilot agent, Claude Code, Codex, Zed's built-in agent | Selects context, calls the model, uses tools, and repeats until a task stops |
| Interface | VS Code panel, Zed panel, terminal, desktop app, cloud task | Where you interact with the harness and review results |
| Tool integration protocol | MCP | Connects an agent to external tools and context sources |
| Agent/editor protocol | ACP | Connects an external agent runtime to an editor interface |
A product can occupy more than one row. For example, an editor can provide an interface and a built-in harness while obtaining model access from a gateway. Ask these questions instead of relying on the product name:
- Which model receives the context?
- Which provider processes it, and under which data policy?
- Which account is billed?
- Which harness can read, edit, execute, use the network, or publish?
- Where can you inspect and revoke those permissions?
Chat Versus Agent Work#
An ordinary chatbot returns text. An enabled coding agent may also:
- search the workspace and read repository instructions;
- edit or delete files;
- run tests, installers, Git commands, and arbitrary terminal commands;
- access external services through built-in tools or MCP servers;
- create commits, push branches, or submit remote work when authorized.
Treat every capability as access granted under your account. A plausible plan or friendly explanation does not make a side effect safe.
The Safe Agent Loop#
Use this loop for one bounded task:
- Explore: request read-only inspection of the relevant instructions, source, tests, and current Git state.
- Plan: agree on the smallest behavior change and affected files.
- Constrain: name files that may change, forbidden actions, data boundaries, and whether network or terminal access is allowed.
- Edit: allow the smallest useful patch.
- Review: inspect
git status, the full diff, and every proposed command. - Verify: personally run the relevant test, lint, type, or smoke checks.
- Record: write what changed, evidence, limitations, and AI assistance.
Use a task packet:
Goal: one observable outcome.
Context: files and instructions to inspect first.
Constraints: files/actions/data that are allowed or forbidden.
Verification: exact checks that must run.
Output: explanation, smallest patch, diff summary, and limitations.
For Euler review, add:
Do not submit, cancel, or modify a Slurm job. Review the script only.
Permissions And Untrusted Instructions#
Read a proposed terminal command before approving it. Prefer one-time approval for a command you understand. Do not choose broad persistent or automatic approval merely to remove prompts.
Repository instructions, issues, web pages, logs, notebooks, dependencies, and tool output may contain instructions aimed at the agent. They are context, not authority. Stop when an instruction requests secrets, unrelated files, administrator rights, disabled safety controls, destructive recovery, or unnecessary network access.
Understand Before Accepting AI Output#
- I can distinguish a model from an agent harness and a gateway.
- I know which account pays for the model request.
- I know that MCP connects tools while ACP connects an agent and editor.
- I can state which files and actions an agent may use for a bounded task.
- I will not treat an agent's reported test result as personal verification.
Verification#
Given the phrase "use GLM through OpenRouter in Zed," you should be able to identify:
- GLM as the model family;
- OpenRouter as the gateway and billing path;
- Zed as the interface and, for its built-in workflow, part of the harness;
- the local keychain as the credential location when the key is entered through Zed's provider settings;
- the human as responsible for permissions, review, and verification.
Common Failure And Safe Recovery#
The agent and model names are being used interchangeably. Stop discussing configuration until you can identify the model, provider/gateway, harness, interface, account, and permissions separately. Use the five questions under The Stack.
Ask For Help When#
You cannot determine which service receives project context, which account is billed, or whether an integration can run commands or access external systems.
Primary Sources#
Verified: 2026-08-26. Review by: 2026-11-26. Owner: lab software maintainer.