From Components to Control Flow: What Should Be Automatic?
The repository has now placed several boundaries around a model: context selects information, schemas shape exchanges, retrieval supplies external material, tools connect language to capability, and protocols make shared capabilities explicit. This checkpoint connects those pieces into one practical judgment: how much control flow should a task receive? The useful answer is conditional. Add the smallest amount of autonomy that the task’s uncertainty and evidence can justify.
That judgment matters because “AI system” is too broad a label to guide design. A context assembler, a retrieval index, an MCP server, a skill package, a workflow, and an agent loop do different jobs. Treating them as interchangeable encourages two opposite mistakes: building a large autonomous system for a predictable task, or forcing an open-ended task through a brittle sequence that cannot adapt when the world differs from the plan.
One task has several flows
A request has at least two flows that must be kept separate. The first is information flow: what the system knows, retrieves, remembers, or observes at each step. The second is authority flow: which component is allowed to invoke a capability, change state, or produce an externally visible effect. Context and retrieval primarily shape information flow. Schemas and protocols make exchanges legible. Tools cross into action. Permissions and verification govern whether that action is acceptable.
The repository’s earlier lessons make this distinction concrete. A retrieved policy can inform a response, but it does not authorize a refund. A tool schema can describe an update operation, but it does not grant the caller permission to run it. An MCP server can expose a capability, but request-scoped policy still decides whether this caller may use it. An Agent Skill can describe a review procedure, but the host still controls which tools and files the procedure can reach.
The same distinction helps explain what a language model contributes. The model can select a tool, propose structured arguments, or decide that more information is needed. The application owns the actual call and returns an observation. A protocol can make that call portable. A workflow can arrange the steps. An evaluation or verification boundary can decide whether the result is sufficient. No single label—model, agent, or protocol—owns the whole system.
A useful test is to draw a task as two parallel traces. On the information trace, mark the question, retrieved evidence, tool result, and generated response. On the authority trace, mark the user’s permission, the application policy, the capability invocation, and the final approval. If those traces are collapsed into one arrow from prompt to action, an important control has probably been left implicit.
Predictability should determine control flow
The repository’s workflow material offers a restraint that is easy to lose in the excitement around agents: start with a direct call or a predefined workflow, then add dynamic behavior only when it earns its cost. A workflow has a path chosen by engineers. It may chain prompts, route different inputs, run independent calls in parallel, ask an evaluator to check a proposal, or have an orchestrator select among bounded workers. The common feature is that the control structure is largely known before execution.
An agent is different in one important respect. It can choose what to do next from the state it observes. That flexibility is useful when the task is open-ended, when the correct sequence cannot be specified in advance, or when exploration is itself part of the work. It also makes behavior harder to bound. The system may take more steps, call unexpected tools, accumulate misleading observations, or stop with a confident but unsupported answer.