Skip to content

Latest commit

 

History

History
75 lines (53 loc) · 3.54 KB

File metadata and controls

75 lines (53 loc) · 3.54 KB

Patterns & rationale

The README lists the practices; this is the why behind the ones that most often get skipped — and the failure modes they prevent.

Least-privilege, per-task credentials

Failure mode: an agent holds broad, long-lived credentials "to save round-trips." One confused command, one prompt-injection in a fetched page, and the blast radius is your whole account.

Pattern: issue a separate credential per scope (read-only here, a single mutating scope there) and source only the narrowest one a task needs. Keep admin credentials out of the shell entirely; source them for one explicit action and drop them immediately. Never let an auth failure silently escalate to a broader credential or an interactive login the agent can't be trusted to drive.

Test: if you env | grep -i key mid-task, you should see only the scope this task required — nothing wider.

Explicit environment before any write

Failure mode: "apply this" with no environment stated, run against prod because that was the last context the shell had.

Pattern: make the target environment a required input for every mutating action. Read-only discovery is fine while you figure out scope; mutations wait until the environment is unambiguous. A single targeted clarifying question is cheaper than a prod incident.

GitOps over imperative changes

Failure mode: an agent fixes something with a live kubectl edit. It works — until the reconciler reverts it, or the next person can't find why prod differs from Git.

Pattern: the agent's job is to change Git, not the cluster. Persistent change lands as a reviewed PR; a reconciler applies it. Emergency manual fixes are allowed only if immediately followed by a PR that codifies them and reconciles state back to Git. This keeps every change reviewable, attributable and revertible.

One writer per branch and environment

Failure mode: two agents (or an agent and a human) edit the same branch or the same environment concurrently and silently clobber each other.

Pattern: bind each session to one branch and one worktree, and take a lightweight lock (a file under a known directory, or whatever your team standardises on) naming the session, branch and environment before writing. If a conflicting lock exists, stop. This is the cheapest possible concurrency control and it prevents the most expensive class of multi-agent bug.

Coordinator + sub-agents

Failure mode: one agent tries to hold the entire task — every file read, every log line — in a single context, gets lossy, and starts making decisions on stale information.

Pattern: treat the main agent as a coordinator. Delegate bounded subtasks (explore this directory, validate this config, run this command set) to sub-agents and pull back only the decision and the diff. The coordinator stays lean and authoritative; the expensive, noisy work happens in disposable contexts.

Forward-only promotion

Failure mode: a change is hand-applied to a higher environment first, or promotions batch up into a giant mixed PR no one can review.

Pattern: introduce change in the lowest environment, then promote forward in a fixed order, in small and frequent PRs. Back-port emergency fixes down the chain immediately so lower environments never silently lag. The result is low drift and reviewable diffs.


None of this is exotic. It's the same discipline good platform teams already apply to humans — least privilege, change control, isolation, review — written down explicitly enough that an autonomous agent can follow it without improvising.