Agent Blueprint Patterns

Blueprints are repeatable workflow templates that ride on top of the workspace. Each blueprint is explicitly configured with its goal, required tools, allowed services, data scope, write permissions, review gate and logging expectations. A prompt is not a security boundary. Autonomous behavior should be constrained by the environment and release controls around the prompt/skill, not by assuming the instructions themselves are sufficient.

Posture Rules

• Start narrow. Default posture is search, read, summarize, draft, propose. Direct writes are the exception.

• Writes to systems of record require explicit human review and approval and are logged.

• Static policy. Allowed services, data scopes, and write boundaries are declared up front, not negotiated at runtime.

• Defense in depth. Layered enforcement: network allowlist, per-service authentication, runtime sandbox, credential proxy, human review of writes. The agent cannot reach services or data outside its declared scope, regardless of prompt.

• Lifecycle ownership. Each blueprint has an owner, a review cadence, an incident contact, and a deprecation path. Blueprints are versioned products, not ad-hoc scripts.

• Always-on by default. Blueprints assume the workspace stays running while the user is offline; the human-review gate is asynchronous, not in-session.

Why writes are conservatively gated. Three convergent concerns, not one:

• Last line of defense. The lethal trifecta has two exfiltration channels: outbound traffic and writes. Outbound traffic — including parameter smuggling under prompt injection — is constrained upstream by the network allowlist and credential proxy. Writes are constrained by the human-review gate, the last line of defense after the upstream controls (sandbox, allowlist, signed policy, credential proxy). Writes are also the hardest to roll back: reads are repeatable; approved writes often aren’t (un-merging a commit, retracting a published doc).

• Accountability and provenance. The reviewer becomes the principal of record/point of accountability for the action; the four-identity attribution chain bottoms out at a real person, not at “the agent did it.” Human-attributed writes stay distinguishable from agent-generated writes — preserving data lineage for future input-trust policies.

• Regulatory alignment. Phase II profiles target regulated industries — finance, healthcare, public sector, defense — where human-in-the-loop on actions of consequence is a compliance requirement, not an architectural preference. The conservative posture is what makes the same blueprint catalogue deployable across both unregulated and regulated tiers.

Any one of these layers would justify the posture. Together they apply the same defense-in-depth logic the architecture uses for network reach, identity, and credential issuance — to writes.

Realization pattern. Agents write to their own branch, repo, or scratch space and propose changes upstream via MR/PR. They never push directly to main or other shared sources of truth. The MR/PR is the human-review gate.

Table 4: Agent Blueprint Patterns

Blueprint	Goal	Typical Services	Permissions Gate
Coding assistant	Read code, explain, draft patches, run tests	Source control, package repos, CI logs, ticketing	Review before commit, merge, or protected-branch write
Documentation assistant	Search docs, summarize systems, draft updates	Docs system, enterprise search, source-controlled docs	Review before publish
Issue triage assistant	Analyze tickets, cluster themes, propose actions	Ticketing, docs, source control, logs	Review before state change or assignment
Developer onboarding assistant	Help new engineers understand repos and workflows	Source control, docs, chat history, package repos	Read-only by default; reviewed drafts only
Research notebook assistant	Run notebooks, inspect data, draft analysis	Notebook environment, data store, package repos	Review before publishing or writing shared data
Operations assistant	Summarize alerts, correlate logs, draft remediation	Logs, tickets, runbooks, chat	Review before executing remediation
Knowledge worker assistant	Search mail, chat, docs, tickets; summarize context	Mailbox, chat, docs, ticketing	Review before send, forward, publish, or delete