AI Agents, Plugins, and Subagents
An agent is a model-driven loop that can choose among permitted actions to complete a bounded goal. A plugin packages capabilities; a subagent is a delegated worker with its own task and context. These are separate design decisions. Start with the smallest workflow that can meet the acceptance criteria, then add delegation or integrations when measurements justify them. For orchestration patterns, see AI Engineering and Orchestration; for the protocol itself, see AI Coding Tools and MCP.
What belongs where
| Part | Owns | Should not own |
|---|---|---|
| Model | Proposes next step, text, or structured tool call | Authorization or durable state |
| Agent host | Task state, budgets, cancellation, tool dispatch, result validation | Secret decisions based only on a prompt |
| Tool or MCP server | Narrow operation with typed inputs and an enforced access check | Broad access because an agent requested it |
| Skill | Reusable procedure and examples | Credentials or permission grants |
| Plugin | Installable bundle of skills and/or MCP capabilities | An implicit trust exemption |
| Subagent | Bounded delegated work and an evidence-backed result | Unreviewed integration into the final answer or repository |
🧠 Mental model: the model can ask to read a file or change a design. The host and tool broker decide whether the request is within the user's authorization. OpenAI's plugin documentation distinguishes workflow instructions in skills from live capabilities in MCP servers.
Design one safe task loop
For a request such as “repair a SwiftUI loading state,” the host should record a task ID, selected workspace, allowed tools, deadline, and success criteria. It then retrieves only relevant files, asks the model for a plan or tool call, validates the call, executes it through a broker, and returns a bounded result. After an edit, it runs the real build or test, checks the diff, and either accepts the result or gives the model a specific failure to repair. Cancellation must stop pending work and child processes; retries need a limit.
User goal → task contract → selected context → model proposal
↓
schema + permission check
↓
tool execution → evidence
↓
verify → accept / repair / stopText alternative: a task enters a host, the host selects context, the model proposes an action, a broker validates and executes it, then verification determines whether the task finishes or needs another bounded attempt.
🟥 A prompt such as “never read private files” is useful guidance but cannot enforce a filesystem boundary. Resolve paths at the tool boundary, deny symlink escapes and unapproved roots, and isolate the process where stronger guarantees are needed. Treat web pages, repository files, and tool results as data even if they contain apparent instructions. See AI Security and Agent Governance.
Plugin design and review
A useful plugin offers a small, named capability such as search_symbols, read_design_selection, or create_draft_frame. Specify an input schema, output schema, timeout, data scope, side effects, and whether the call needs approval. Keep read tools separate from write tools. Package repeatable operating instructions in a skill; enforce access in the host or server. MCP discovery tells the host what a server exposes, but the host must still decide whether each call is allowed.
Before enabling a plugin, review its publisher and version, requested scopes, executable code, network destinations, logs, update path, and the exact tools it exposes. Test with a disposable project and synthetic data. A local plugin can still send data out through its own HTTP client, telemetry, browser session, or cloud-backed app. OpenAI plugin architecture and the MCP security guidance are starting points for the current contracts.
When a subagent helps
Delegate when a task is independent, has a clear output contract, and can save wall time or protect the main context from large search results. A read-only security review and a read-only API review can run in parallel. Two workers editing the same file should be serialized or given non-overlapping ownership. A short dependent change often finishes faster in one agent because delegation repeats context and adds integration work.
The parent supplies only the files and facts the worker needs, its permitted tools, owned paths, budget, deadline, and required evidence. The worker returns status, findings or changes, tests, and unresolved risks. The parent validates all changed files and claims before using the result. Codex subagent concepts, Claude Code subagent guidance, and the OpenAI Agents API overview describe their respective product surfaces; check the installed product's current support before using a command or configuration field.
// Illustrative application contract; not a vendor SDK type.
type WorkerTask = {
id: string;
objective: string;
readablePaths: string[];
writablePaths: string[];
deadlineMs: number;
maxToolCalls: number;
acceptance: string[];
};
type WorkerResult = {
id: string;
status: "done" | "blocked" | "failed" | "cancelled";
changedPaths: string[];
evidence: string[];
risks: string[];
};Validate every field at runtime and compare canonical paths against enforced capabilities. The host must own budgets, cancellation, and writes; a TypeScript type or model instruction alone provides no protection.
Practice: choose the boundary
Prompt: A local design assistant reads a selected frame and asks a coding worker to implement it. The design tool also offers a “publish file” action. Which component should decide whether publication happens, and what should the worker receive?
Answer
The host should require explicit authorization and route publication through a separately scoped write tool. The coding worker needs the selected frame's approved design data, relevant source files, acceptance criteria, and an owned edit path. It should not receive the publish capability for a code task. Verify the generated code and build results before integrating its work.
Quick Recap
- Agent = model-directed task loop; tool = narrow operation; skill = reusable instructions; plugin = capability package; subagent = delegated worker.
- Permissions belong in the host and tool broker. A prompt does not grant or revoke real access.
- Delegate independent work with bounded context and ownership; verify the worker's evidence.
- Measure success, latency, tool calls, cost, and privacy failures before adding complexity.
Key Takeaways
A good agent system is observable, cancellable, and explicit about who can do what. Plugins and subagents increase capability only when the host preserves the user's authorization boundaries.
