Agentic Workflows

Overview

An agentic workflow is one where an AI model takes a sequence of actions — reading files, running commands, calling APIs, writing code, submitting pull requests — with minimal or no human approval at each step. Agentic workflows are qualitatively different from single-turn AI interactions: the model's outputs become inputs to further actions, compounding both capability and risk.

The question for a team adopting agentic workflows is not "can agents do this?" but "should agents do this without a human in the loop, and if so, under what conditions?" This page provides the framework for answering that question.

For day-to-day AI tool usage at lower autonomy levels, see AI Code Assistants. For how agentic tools interact with the codebase context, see Context Engineering. For reviewing agent-produced pull requests at the code level, see Code Review.

---

Why It Matters

Agentic workflows amplify both productivity and blast radius. An agent that can write code, run tests, fix failing tests, and open a pull request with no human steps can complete multi-hour tasks in minutes. An agent that takes an incorrect action at step 3 of a 10-step workflow can produce a result that looks complete but is substantively wrong — and the human reviewing the PR may not reconstruct the path that produced it.

Autonomy is appropriate in some contexts and dangerous in others. Running an agent that generates and runs test cases in an isolated sandbox is a very different risk profile from running an agent that makes API calls to production, modifies infrastructure, or submits code to a shared branch. The level of autonomy granted should match the reversibility of the actions being taken.

Review standards for agent-produced code differ from standards for human-produced code. Humans produce code with intent they can articulate; agents produce code that satisfies the stated requirements and may silently satisfy them incorrectly. The reviewer's task is different: less "does the author understand what they wrote?" and more "does this code correctly solve the actual problem, regardless of how it was generated?"

Teams that have not defined agentic guardrails before something goes wrong define them during the incident. The appropriate time to decide what an agent is and is not allowed to do is before the first run, not after the first mistake.

---

Standards & Best Practices

Define the autonomy level before running an agent

Not all agentic tasks require the same level of autonomy. Map tasks to a tier before running:

The default should be Checkpoint or Autonomous with review. Fully autonomous is appropriate only for tasks that are clearly bounded, reversible, and have been run at the checkpoint level enough times to validate the agent's output quality.

Define what actions the agent is and is not permitted to take

Before running an agent on any new task class, define explicitly:

Allowed:

• Read access to source code, documentation, test output
• Write access to branches the agent creates (not shared or protected branches)
• Ability to run tests and linting in an isolated environment
• Ability to create pull requests for human review

Require explicit approval before proceeding:

• Writing to shared infrastructure configuration
• Making API calls to external services
• Modifying database schemas
• Accessing credentials or secrets
• Sending external communications (emails, Slack messages, webhooks)

Never allowed:

• Pushing directly to main/production branches without PR
• Deleting or overwriting production data
• Rotating or exposing credentials
• Bypassing access controls to complete a task

These boundaries must be enforced by tooling, not just stated in a prompt. An agent that is told "don't push to main" but is given credentials and write access to main may still do so if the task seems to require it.

Sandbox agent execution

Agentic workflows that run code should run it in an isolated environment:

• A fresh container or VM per agent run, discarded after completion
• No persistent access to production credentials, databases, or services
• Network access scoped to what the task actually requires
• File system access scoped to the repository or working directory, not the host

The purpose is not to prevent the agent from doing useful work; it is to ensure that the worst-case outcome of an unexpected agent action is "the container is discarded" rather than "something in production changed."

Agent-produced code requires differentiated review

A pull request produced by an agent should be reviewed with a specific lens:

For agent-produced PRs, ask:

• Does the code solve the actual problem, or a superficially similar problem?
• Are there edge cases or failure modes the agent handled incorrectly but confidently?
• Does the implementation follow the conventions the agent was given, or did it invent alternatives?
• Are the tests the agent wrote testing the right things, or testing the agent's own assumptions?
• Is there anything in the diff that should not be there (unintended file changes, credentials, debug output)?

The reviewer should not assume the agent understood the requirements. Agents produce code that satisfies the stated specification; they do not understand the unstated requirements, the existing constraints, or the reasoning behind conventions. The reviewer's job is to verify that the output is correct, not just that it looks correct.

Standard code review applies in addition. Agent-produced code is not exempt from the review standards in Code Review — it is subject to them with heightened scrutiny.

Log agentic runs and keep the audit trail

Every agentic run should produce a log that captures:

• What task was given to the agent
• What actions the agent took, in order
• What the agent produced
• Who triggered the run and when

This log is necessary for:

• Debugging when the agent's output is wrong
• Auditing when questions arise about how a change was made
• Building a track record that justifies expanding the agent's autonomy over time

A team that cannot reconstruct what an agent did cannot learn from its mistakes.

Expand autonomy incrementally

New agentic workflows should start at the Checkpoint tier and move toward Autonomous with review only after the team has observed enough runs to have confidence in the agent's output quality for that task class.

Signals that justify expanding autonomy:

• The team has reviewed N consecutive runs without finding a substantive problem
• The task class is well-defined and rarely produces edge cases
• The blast radius of a wrong output is low and the error is clearly visible in the PR
• Rollback from an incorrect agent output is fast and well-understood

Expanding autonomy is a deliberate team decision, not a default that happens as agents become more capable.

---

How to Implement

Before running a new agentic workflow

• Task class and autonomy tier have been agreed by the team
• Allowed and disallowed actions are defined and enforced by tooling (not just by prompt)
• Agent runs in a sandboxed environment with scoped credentials
• Logging and audit trail are in place
• Review process for agent output is defined

Running agents on existing codebases

The best context for an agent working on an existing codebase is the project's context file (see Context Engineering). Before running an agent:

• Verify the context file is current
• Verify the agent has access to the relevant documentation and test suite
• Start with a narrow, well-scoped task rather than a broad one
• Review the first several runs at the Checkpoint tier before any autonomy expansion

---

Common Pitfalls

Prompt-only guardrails. Telling an agent "do not push to production" in the prompt is not a guardrail — it is a suggestion. Guardrails are enforced by the environment (permission scoping, branch protection, sandboxing), not by the prompt.

Reviewing agent PRs as if they were human PRs. A human who wrote code can explain their reasoning; an agent cannot. The review checklist is different. Agent PRs require the reviewer to reconstruct whether the output is correct, not just whether it is well-written.

Expanding autonomy based on capability, not trust. A model that is more capable is not automatically trustworthy for higher autonomy. Trust comes from observed track record on the specific task class, not from general model capability.

Using agents for tasks where the specification is ambiguous. Agents produce outputs that satisfy their specification. If the specification is ambiguous, the agent will satisfy one interpretation — possibly not the one you intended. Agentic workflows are most reliable for well-defined task classes.

No audit trail. An agentic change with no log of what the agent did is a change whose provenance cannot be verified. This becomes a compliance problem, a debugging problem, and a trust problem. Log everything.

Running agents with production access "temporarily." Production credentials given to an agent for a one-off task have a habit of persisting in configuration, environment variables, or logging. Scope credentials to the minimum and revoke them after the run.