Direct answer
Guardrails are architectural rather than textual. The agent holds a small set of named operations, permissions are enforced by the systems it calls, consequential actions wait for a named approver, writes tolerate a retry, and refusals come back as structured reasons. Prompt wording helps at the margin; these hold when it fails.
AI agent guardrails
The enforced limits on what an agent can do, placed in the surrounding system rather than in its instructions. They constrain which operations exist, whose authority a call carries, which actions require approval, and what happens when a request is refused.
Where a guardrail actually sits
A limit that lives only in a prompt is a request. These are limits the agent cannot talk its way past.
The tool contract
The agent can call only named operations with explicit inputs. An operation that does not exist cannot be invoked.
The permission check
The system being called refuses an unauthorised request on its own, regardless of who asked or how the request was worded.
The approval gate
Consequential actions stop for a named human, with risk tier deciding who may approve.
The executor split
A separate component performs approved work, so the agent never holds a write tool to the outside world.
Idempotency
A repeated write is absorbed rather than duplicated, because an agent under a retrying orchestrator will repeat itself.
Budget limits
Caps on tokens, calls and wall-clock time, so a reasoning loop ends rather than running.
Refusals are a feature, not an error
A refused action should return a structured reason the agent can reason about and a person can read, and it should be recorded. A guardrail that has never refused anything has not been demonstrated, so refusals belong in the log beside successes and are the earliest signal that inputs or interfaces have changed.
Guardrails against untrusted content
An agent reading a record's notes, a document or a web page is reading input that may contain instructions aimed at it. Treat retrieved content as data, never as instructions, and design so the worst outcome of an injected instruction is a refused call and a log entry rather than an action.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work — merge, publish, call, write — and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
Are prompt-level rules worth writing at all?
Yes, as a first filter that reduces obviously wrong attempts. They are not a control, because they fail silently and cannot be demonstrated to an auditor. Write them, then assume they will be bypassed and make sure something enforced sits underneath.
Does every action need an approval gate?
No, and applying one everywhere trains reviewers to click through. Gate actions by consequence: changes to customer-visible records, money movement, and anything hard to reverse. Reads and internal drafts generally do not need one.
What is the most commonly missed guardrail?
Idempotency on writes. Teams design the permission model carefully and leave retries unhandled, so a timed-out call that actually succeeded gets repeated and creates a duplicate nobody notices until reconciliation.
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.