Configuration of Agentic Systems
Configuration is code
Everything that shapes agent behaviour should be versioned in the repository and reviewed like code: instruction files (repo conventions, build and test commands, "do not touch" paths), custom agent definitions, the tools and MCP servers an agent may call, workflow YAML permission blocks, and environment protection rules. Configuration drift is the most common cause of "it worked last week".
The knobs to know
- Instructions - style, build/test commands, architectural constraints, forbidden paths.
- Tools - which servers, CLIs, or APIs the agent may invoke; allowlists beat denylists.
- Permissions - per-workflow
permissions:blocks, short-lived tokens, no long-lived personal access tokens. - Environment - sandboxing, network egress, secrets scoped to an environment with required reviewers.
- Triggers - which events start a run (issue assignment, label, comment, schedule).
Trap: instructions are advisory
A sentence in an instructions file is a prompt, not a control. If the agent must never modify infra/, that is enforced by CODEOWNERS plus a CI check that fails on those paths, plus branch protection requiring that check. Exam questions love the gap between instructed and enforced.
Trap: over-privilege
permissions: write-all or a classic token with broad repo scope converts one prompt-injection bug into a supply-chain incident. Default to contents: read and add the minimum extra scope per job, per stage.
Rule of thumb
For every capability you give an agent, ask: "what enforces this if the model ignores the instruction?" If the answer is "nothing", it is a suggestion. Wire it to a CI check, a permission boundary, or a named reviewer.