The Agentic Development Blueprint

The Building Blocks

Understanding the pieces before you put them together.

What Is an Agent?

Before you can protect an agent, you need to understand what it actually is — and what it isn’t.

An LLM is expensive software

Strip away the hype and a large language model is a function: text in, text out. It predicts the next token based on everything it has seen — both during training and in the current conversation. That’s it.

It’s expensive software because each token costs compute. More tokens in the conversation means more memory, more processing, and more money. This matters because it creates a hard constraint: the context window is finite, and every token you put in it has a cost.

The context window problem

The context window is the total amount of text the model can “see” at once — your instructions, the conversation history, file contents, tool results, everything. Modern models have large windows (100K–200K tokens), but here’s the catch most people miss:

Why? Because the model’s attention degrades as context grows. Important instructions get diluted by irrelevant file contents. Critical conventions get buried under walls of boilerplate. The model starts “forgetting” things at the top of the window as new content pushes in at the bottom.

This is why context engineering matters so much — it’s the discipline of putting the right tokens in the window, not just more tokens.

What makes it an “agent”

An LLM becomes an agent when you put it in a loop:

1. Receive a task (from a human or another system)
2. Think about what to do next
3. Use a tool (read a file, run a command, make an API call)
4. Observe the result
5. Decide if the task is complete — if not, go back to step 2

That’s the agent loop. The model keeps cycling through think → act → observe until it decides it’s done. Each cycle adds more tokens to the context window, which is why long-running agents eventually degrade — they fill their own window with conversation history.

How tools actually work

Tools aren’t magic. Here’s what happens under the hood:

1. The model sees a list of available tools (names, descriptions, parameter schemas)
2. When it decides to use a tool, it outputs a specially formatted token sequence — essentially a JSON function call
3. The runtime intercepts that output, executes the actual tool (reads a file, runs a shell command, calls an API)
4. The tool result is injected back into the context as a new message
5. The model continues with the result now visible in its window

The model never “runs” anything itself. It produces text that the runtime interprets as a tool call. This is important because it means tool definitions are context — they consume tokens in the window, and their quality directly affects whether the model uses them correctly.

Why this matters for everything that follows

Understanding the agent loop explains why every concept in this blueprint exists:

• Context engineering exists because the window is finite — you need the right tokens, not all the tokens
• Deterministic enablement exists because the model is probabilistic — you can’t trust it to always follow instructions, so you enforce critical rules with code
• Delegated agents exist because one agent’s context window degrades — splitting work across fresh agents keeps quality high
• Workflows exist because agents need structured operating patterns to produce reliable results at scale

Context

Before transformation, understand the layers of context your agent actually operates with.

Context is the first building block because it shapes what the agent can see before any tool call or workflow step happens. As we covered in What Is an Agent?, the context window is finite and every token matters. Some context is always present, some is pulled in only when it is relevant, and some is injected by deterministic systems after the agent acts.

That distinction matters. If you treat all context as one blob, you end up with either overloaded instructions or missing guidance. If you separate it into static, dynamic, and injected layers, you can design for clarity instead of hoping the model figures it out.

Static Context

Static context is the always-on layer — the things an agent can count on finding in the repo every time it starts working.

• copilot-instructions.md (or .github/copilot-instructions.md) — your architectural direction, boundaries, conventions, and standards.
• README files — top-level orientation and local module guidance.
• Documentation folders like /docs — compaction files, architecture notes, and AI-readable maps of the system.
• Any markdown files the agent reads automatically — the durable, repo-native context you want available by default.

This is the foundation layer. It should be stable, curated, and low-noise because it is the baseline the rest of your system builds on.

Dynamic Context

Dynamic context is what you load when the task calls for it. It keeps the always-on layer lean while still letting the agent access deeper guidance at the moment it matters.

Skills

The distinction between skills and hooks matters:

• Skills capture procedural knowledge — how to do something. “When deploying to staging, run these 5 steps in this order.” “When creating a new API endpoint, follow this pattern.” Skills are flexible — the agent interprets and applies them contextually.
• Hooks capture deterministic constraints — things that must always (or never) happen. “When editing file X, always update file Y.” “Never modify the auth middleware without a security review.” Hooks are rigid — they execute code, not instructions.

Rule of thumb: If the enforcement is “always/never do X,” it’s a hook. If the enforcement is “here’s how to do X well,” it’s a skill.

Memory

For agents that run across multiple sessions, persistent memory lets them learn:

• Corrections become rules. When you correct the agent (“no, we use kebab-case for file names”), that correction gets persisted so it never makes the same mistake again.
• Patterns become conventions. When the agent discovers a pattern that works, it gets recorded for future reference.
• Decisions become context. When a choice is made (“we chose PostgreSQL over MongoDB because…”), the reasoning is preserved so future agents don’t revisit settled decisions.

The system gets better every time it runs — not through model fine-tuning, but through accumulated structured context that makes the agent’s decisions more aligned with your team’s expectations.

Injected Context

Injected context is the bridge between probabilistic guidance and deterministic enforcement. A hook can run a deterministic process and then add additionalContext back into the model’s working state after the action completes.

That is incredibly powerful because you control the signal quality. A post-tool hook can inject lint results, test results, policy checks, or focused analysis immediately after an edit, which means the next model decision is grounded in real, current evidence instead of vague instructions.

This is how you move from “I hope the model remembers the rule” to “the system just handed the model the exact constraint it needs right now.”

Deterministic Enablement

Your agent’s safety isn’t one thing. It’s controlled capability, lifecycle gates, and environment boundaries working together.

Most teams think “agent safety” means writing better instructions. That is one layer — and it is the weakest one. As we saw in the Context section, instructions steer intent but can’t guarantee behavior. Real protection combines invocable tools, guarded lifecycle hooks, and sandboxing so the agent operates inside a structure instead of improvising inside a void.

Invocable Enablement (Tools)

A tool is structured context given to the model. The model sees the tool definition, decides whether to call it, and then the tool executes. It is not magic. It is a clearly described capability that the model can invoke when the task requires it.

Tools are usually defined in one of two ways:

1. MCP servers — the most common path, using a standardized protocol to expose safe, explicit capabilities.
2. GitHub Copilot CLI extensions — especially powerful because they can create tools dynamically as your workflow or repo state changes.

Tools (controlled capabilities) replace open-ended access with specific, safe actions:

• A “deploy preview” tool that creates a preview deployment for the current PR
• A “run tests” tool that executes the test suite and reports results back
• A “check coverage” tool that verifies coverage meets your thresholds

The pattern: instead of giving the agent bash and hoping for the best, give it named tools that do specific things safely. The agent can only use what you expose.

Guarded Enablement (Hooks)

Hooks run deterministic processes at specific lifecycle points. They are not AI — they are code — which means they are reliable in a way prompt text never will be.

• Pre-tool hooks run before a tool executes and can deny the action entirely. Example: run tests before a push and block the push if the suite fails.
• Post-tool hooks run after a tool executes and can inject context back into the session. Example: run a linter after an edit and add the lint results to the agent’s context.

The deeper insight is that hooks are incredible context amplifiers. Because you control the deterministic process, you control the quality of the context being injected. Deterministic process in, high-signal context out.

Sandboxing

Here’s the uncomfortable truth: a sufficiently capable agent can work around your hooks.

Example: your hook blocks direct edits to .env. So the agent writes a shell script that edits .env — and executes it. The hook never fires because the agent didn’t use the edit tool on .env. It used the shell tool to run a script that did the editing.

This isn’t hypothetical. This is the class of problem that sandboxing solves:

• Network gating. The agent’s execution environment can only reach approved endpoints. No arbitrary HTTP calls, no downloading unknown packages, no exfiltrating code to external services.
• Filesystem isolation. The agent operates in a restricted filesystem scope. It can’t reach outside its workspace to access credentials, secrets, or system files — even indirectly through scripts.
• Credential isolation. Secrets are injected at runtime, not stored in files the agent can read. The agent uses an API through a tool, but never sees the API key.
• Process sandboxing. Agent-spawned processes inherit the same restrictions. A script can’t escalate privileges beyond what the agent itself has.

The key insight: Context steers behavior (probabilistic). Deterministic controls gate specific actions (reliable but bypassable). Sandboxing prevents circumvention by restricting the environment — there’s nothing to bypass because the capability doesn’t exist.

Why you need all three layers

Each layer is weak alone. Together, they’re defense in depth:

1. Context tells the agent not to touch .env → works most of the time
2. A hook blocks .env edits → catches the cases where context fails
3. Sandboxing prevents the agent from writing scripts that modify .env → catches the edge case where the agent circumvents the hook

This is the three-layer cake. It takes your agent from “mostly safe” to “structurally safe.”

Delegated Agents

When one agent isn’t enough — and why splitting work across agents produces better results than one agent doing everything.

The single-agent ceiling

There’s a natural limit to what one agent session can accomplish. As we covered in What Is an Agent?, every tool call, file read, and conversation turn adds tokens to the context window. Eventually the agent is dragging around so much history that its output quality drops — it starts repeating itself, forgetting early instructions, or making decisions that contradict things it did 50 turns ago.

The fix isn’t a bigger context window. The fix is delegation: spawning a new agent with a fresh context window, a focused task, and only the context it needs to do that one thing well.

Why delegation equals quality

A delegated agent gets:

• A clean context window. No conversation history from unrelated work. No stale file contents from earlier tasks. Just the instructions, the relevant files, and the task — pure signal.
• A focused scope. “Fix the auth middleware” instead of “keep working on everything.” Narrow scope means fewer decisions, which means fewer mistakes.
• Isolation from other work. If a delegated agent makes a mess, it’s contained to its branch and its PR. It doesn’t pollute the parent agent’s state or other workstreams.

This is the same reason you wouldn’t assign one developer to work on 12 features simultaneously without ever closing a tab. Context switching degrades quality for humans and agents alike.

The delegation pattern

In practice, delegation works like this:

1. Orchestrator agent receives a complex task or a set of tasks
2. Breaks it into sub-tasks that can be done independently
3. Spawns focused agents — each one gets a clean session with just the context it needs
4. Agents work in parallel on isolated branches (see Workflows for worktrees)
5. Results flow back as PRs, reports, or completed artifacts

The key insight: the orchestrator doesn’t do the work — it coordinates work. Its context window stays lean because it only holds task definitions and results, not the full implementation detail of every sub-task.

When to delegate vs. keep in one session

Connection to context compaction

Delegation and context compaction (covered in Part 2) are two sides of the same coin. Compaction compresses knowledge so it fits in one window. Delegation splits work so each window stays fresh. The best agentic systems use both: compacted context for baseline knowledge, delegation for parallel execution.

Workflows

Once the pieces are in place, you need repeatable operating patterns that keep humans and agents moving in parallel.

By this point your agent can operate with context and guardrails, and you know how to delegate complex work. The next move is to turn the work itself into a system: isolated execution, clean handoffs, and workflows compacted into repeatable patterns.

Worktrees

Git worktrees are not conceptual lanes. They are additional folders on your filesystem, each with the repo checked out on a different branch. That means you can literally have multiple copies of the same repository open at once:

/my-project/           ← main branch (your primary working directory)
/my-project-feature-a/ ← feature-a branch (worktree #1)
/my-project-bugfix/    ← bugfix branch (worktree #2)

Each folder is a complete copy of the repo with its own branch. You can work in one while an agent works in another and CI runs against a third. No stashing. No branch switching. No losing your place.

What parallel work feels like in practice

Issues as agent work items

Create GitHub issues with clear acceptance criteria and assign them to your AI agent (Copilot Coding Agent, or similar). The agent picks up the issue, creates a branch, does the work, opens a PR, and requests review. You review the PR, not the process.

This is the workflow that scales: you become the architect and reviewer, the agent becomes the implementer. Your job is to write good issues and review good PRs — not to write every line of code.

Compact what works

When you find a workflow that consistently produces good results — a specific way of structuring prompts, a particular sequence of agent actions, a review checklist that catches real issues — don’t keep it in your head. Write it down:

• Workflow templates that describe the steps
• Issue templates with the right structure for agent consumption
• Review checklists that focus on what agents actually get wrong

Go Agentic

The step-by-step transformation from messy repo to governed workflow.

Clean Up Your Codebase

Before good context, you need a well-structured solution.

This is the step nobody wants to do — and it’s the one that makes everything else work. A messy codebase produces messy AI output. Dead code, stale documentation, tangled dependencies, god classes — all of it becomes noise that pollutes the agent’s context window.

What “clean up” means in practice

This isn’t a months-long refactoring project. It’s targeted cleanup focused on reducing noise for AI consumption:

• Go through your technical debt backlog. Not all of it — focus on the items that create confusing context. That deprecated module that’s still imported? The config file for a feature you removed two years ago? The three different logging patterns across the codebase? Those are the ones that make agents produce inconsistent output.
• Align your module structure. Proper separation of concerns isn’t just good engineering — it’s what allows an agent to work on one area without accidentally breaking another. If your business logic is tangled with your data access layer, every agent edit becomes a game of whack-a-mole.
• Remove context that doesn’t apply anymore. Dead code, commented-out blocks, outdated READMEs, stale TODO comments referencing tickets that were closed three sprints ago. Every piece of obsolete context is a potential source of confusion for the agent.
• Standardize patterns. If you have three different ways to do error handling, the agent will pick whichever one it sees first — which might not be the one you want. Reduce to one canonical pattern per concern.

The principle

A well-structured codebase is a well-maintained codebase. And a well-maintained codebase is one where AI agents can actually be productive — because the signal-to-noise ratio is high enough that the model can figure out what you actually want.

How to clean up — agentically

The move here is to stop treating cleanup like a manual audit and start treating it like an interrogation. You do not need to personally rediscover every inconsistency in the repo. Use the agent to surface the mess for you.

1. Explain your codebase to the agent. Give it the top-level overview: what the repo does, how it’s organized, what the major components are, and where the sharp edges probably live.
2. Ask the agent to analyze, not implement. Prompt it with questions like: “What patterns do you see?” “What looks inconsistent?” “What’s dead code?” “Where are the anti-patterns?”
3. Let the agent find what you’ve normalized. You’ve been staring at the same codebase every day. You have blind spots. The agent doesn’t. It reads every file fresh and notices mismatches you’ve stopped seeing.
4. Co-plan the cleanup. The agent proposes a cleanup plan, you prioritize what matters, and then the agent executes the work in a controlled sequence.

The key insight is simple: you’ve developed familiarity bias. The agent hasn’t. Let it interrogate the codebase for you, report what it finds, and then use that fresh read to drive targeted cleanup.

Establish Context

The first step in protecting your agent is proper context.

In a brownfield repo — which is most repos — the agent needs to understand what already exists before it can safely make changes. This is where you apply the context layers from Part 1 in practice. The problem is that most codebases are too large for an agent to comprehend by reading every file. You need a compacted representation.

Approach 1: One-shot generation

This is the simplest possible move: ask the agent to generate a copilot-instructions.md based on the repo. Literally: Analyze this repo and create a copilot-instructions.md.

It works. It’s fast. And it gives you maybe 60% of the value right away because the agent will usually extract the obvious architecture, a few conventions, and some useful rules of thumb.

The limitation is depth. On a simple repo, that’s fine. On a complex repo, it gets shallow fast. It misses nuance, overgeneralizes patterns, and occasionally gets the architecture wrong because it only built a thin slice of understanding.

Approach 2: Structure + Priorities (the two-section pattern)

A better pattern is to split copilot-instructions.md into two sections:

1. Codebase structure — what the repo is, how it’s organized, the major components, and the key patterns that are structurally true.
2. Priorities — what matters most right now, what standards are currently being enforced, and what the agent should optimize for in active development.

This is much more durable than one-shot generation because structure changes slowly while priorities change constantly. As you correct the agent, you update the priorities section. The instructions evolve with the work instead of freezing your first guess forever.

That’s the beginning of a self-improving loop: the more you work with the agent, the sharper your priorities become, and the sharper the agent becomes in return.

Approach 3: Learn from development sessions

The highest-signal context often comes from real sessions, not from static repo analysis. Use tools like /chronicle improve (or the equivalent in your stack) to learn from actual development work.

In this mode, the agent watches how you work: what corrections you make, which patterns you reinforce, what kinds of PR comments keep repeating, and where you redirect it when it takes the wrong path.

That matters because observed behavior beats aspirational documentation. Teams are often bad at describing how they want work done, but very consistent about correcting work when it’s wrong. Session learning extracts the reality, not the fantasy.

Approach 4: Advanced context compaction

This is the deepest and most effort-intensive version — the pillar-based research approach. It is the most thorough option, but it asks the most from you up front.

1. Have the agent analyze the repo first. Before asking it to write code, ask it to understand the codebase. Have it identify the top-level architecture — the major pillars, the key services, the data flow patterns.
2. Identify the pillars. Every codebase has 3-7 major segments. For a web app, it might be: API layer, business logic, data access, authentication, background jobs, and frontend. For a platform, it might be: agents, extensions, data layer, infrastructure, and communication.
3. Delegate deep research into each segment. This is where parallel agents shine. Spin up a research agent for each pillar — each one goes deep into its section, reads every file, traces the call chains, maps the dependencies, and produces a compacted markdown file summarizing what it found.
4. Go multiple layers deep if needed. If a pillar is complex (e.g., your API layer has 200 endpoints), have the agent break it into sub-segments and research each one independently. The goal is comprehensive coverage without context window overflow.
5. Output: a folder of well-indexed markdown files. Each file represents the agent’s compressed understanding of one segment of your codebase. These become the navigation layer that future agents use to orient themselves.

Once you have the compacted research, go through all documents and extract two things:

• Architectural direction → goes into your copilot-instructions.md (or equivalent agent configuration). This is the high-level “here’s how we build things here” guidance: preferred patterns, naming conventions, architectural boundaries, testing requirements.
• Navigation context → goes into a docs/ folder with detailed compaction files. These give agents the ability to find what they need without reading every source file. Think of them as an AI-readable map of your codebase.

Which approach should you use?

• Starting from zero? Begin with Approach 1, then quickly evolve into Approach 2.
• Active development team? Approach 3 usually produces the highest-signal context.
• Large complex codebase or brownfield enterprise? Approach 4 is worth the effort.
• What happens in practice? Most teams end up combining Approaches 2 + 3.

Learn Development Patterns

Your commit history is a goldmine of context the agent has never seen.

Most teams skip this entirely — and it’s one of the highest-leverage things you can do. Your Git history contains years of encoded team knowledge about how things should (and shouldn’t) be done.

What to extract from history

• Commit patterns. How does your team structure commits? What’s the typical scope of a change? Are there patterns in how features are developed (branch naming, commit message format, PR size)?
• PR review comments. This is where the real gold is. Every “please don’t do it this way” and “we prefer X over Y” in your PR history is a convention that should be codified. The agent has no access to this history unless you extract it.
• Revert changes. Every git revert is a lesson. What was tried and failed? What patterns were introduced and immediately backed out? These are the “don’ts” that are hard to discover from the current codebase state.
• Co-changed files. When file A changes, which other files always change with it? These coupling patterns tell the agent about implicit dependencies that aren’t expressed in imports or type signatures.

Codifying what you find

Take the patterns you extract and save them as explicit conventions in your instructions file:

## Development Conventions (learned from commit history)
- Error handling: always use the Result<T, AppError> pattern (not try/catch)
- API responses: use the StandardResponse wrapper (see src/shared/response.ts)
- Database queries: always go through the repository layer, never direct SQL
- When modifying a migration, always update the corresponding seed file
- PR scope: one logical change per PR, max ~400 lines of diff

This is the difference between an agent that writes code “from scratch” and an agent that writes code that looks like your team wrote it.

Build Your Safety Net

PRs are the center of agentic development. Make them deployable.

If you don’t have a solid CI/CD pipeline, everything else in this blueprint is compromised. The agent will produce code, you’ll merge it, and you’ll discover it’s broken in production. DevOps isn’t optional for agentic development — it’s the safety net.

The minimum viable test suite

If you have no tests, start here:

• Unit tests are the bare minimum. They verify individual functions work correctly in isolation. For agentic development, they’re necessary but not sufficient.
• Integration tests are more valuable than unit tests for agentic work. Here’s why: agents rarely break individual functions. They break the interactions between components — the API endpoint that now returns a different shape, the middleware that runs in a different order, the database query that works but returns unexpected results when combined with the new business logic. Integration tests catch these.
• Create a simple CI pipeline. GitHub Actions, Azure DevOps, whatever your team uses. The pipeline should run on every PR and block merge if tests fail. This is non-negotiable — it’s the most basic guardrail against agent-produced regressions.

Tightening the DevOps loop

The key insight for agentic development: PRs must be isolated and independently testable.

When an agent works on a feature, it creates a PR. That PR needs to be:

1. Buildable — the CI pipeline builds it successfully
2. Testable — all tests pass (existing and new)
3. Deployable — ideally to a preview environment where you can verify it works
4. Reviewable — the diff is small enough for a human to sanity-check

If any of these fail, the agent’s work is useless regardless of how “smart” the model is. The DevOps infrastructure is what turns agent output into shippable code. Combined with the deterministic controls from Part 1, this creates a system where agent output is both safe and verified.

Trust and Distrust

Start by distrusting the agent. Assume it will break things. Assume it will misunderstand architecture. Assume it will take the shortest path unless your system stops it. Build guardrails from that assumption.

Then, as the agent proves reliable in your codebase, extend trust gradually. Move from reviewing every PR manually to spot-checking. Move from blocking CI to advisory CI in domains where the failure modes are already controlled. Let trust follow evidence, not optimism.

The trust gradient looks like this: Full review → Spot check → Auto-merge with tests → Full autonomy. But full autonomy only belongs in well-tested, well-guarded domains.

The key insight: trust is earned per domain, not globally. You might trust the agent to build UI components today and still refuse to let it touch auth logic without a human in the loop.

Brownfield vs Greenfield

Greenfield is the easy mode. You can set up clean context, consistent patterns, strong tests, and a disciplined CI pipeline from day one. The agent starts in a world designed for it.

Brownfield is where most teams actually live: legacy modules, inconsistent patterns, partial test coverage, undocumented decisions, and plenty of code that “works” but nobody wants to touch. That’s exactly why the cleanup step matters so much.

The brownfield trap is saying, “We’ll refactor later.” Later never comes. Meanwhile, the codebase stays inconsistent, and the agent keeps producing inconsistent output because the repo itself is sending mixed signals.

The tactical answer is not to clean everything. Clean the modules you want the agent to work in first. Create islands of quality. Let the agent operate safely there. Then expand those boundaries over time.

Testability First — Why Tests Are Everything

Here’s the provocative version: in agentic development, tests are not a nice-to-have. They’re the only reliable feedback mechanism that scales.

Without tests, you’re reviewing every line of AI-generated code manually. That means your throughput is capped by human attention. It does not matter how fast the agent writes if you still have to reason through every diff like a detective.

With tests, you review the feedback loop instead of the entire implementation. The agent can open 100 PRs and you immediately know which ones are structurally safer because the tests passed.

That makes testability the highest-ROI investment in agentic development. Better seams, better observability, better assertions, better preview environments — all of it compounds.

Velocity — The Real Promise

When DevOps, testing, and context are all in place, velocity becomes the payoff. This is where the promise gets real.

In Hector’s workflow, work that used to take a developer six hours can collapse into roughly thirty minutes of agent execution plus human review. That is not because the agent is magically better at coding. It’s because the surrounding system compresses the cost of iteration.

But velocity without guardrails is destructive. You’re not creating leverage — you’re just shipping broken things faster.

The equation is simple: Velocity × Quality = Value. If quality drops to zero, velocity is worthless.

Iterate & Improve

When AI “throws up,” don’t say “AI sucks” — ask “why did it fail here?”

This is the mindset shift that separates teams that struggle with AI from teams that get exponentially better at it. Every agent failure is a diagnostic signal, not a verdict.

The diagnostic framework

When the agent produces bad output, run through this checklist:

1. Was the context wrong? Did the agent have access to the right files? Did it see outdated patterns? Was the relevant documentation missing or stale?
2. Was a guardrail missing? Could a pre-commit hook have caught this? Should there be a rule that says “never modify files in /config without approval”?
3. Was the instruction unclear? Did you ask for “a login page” when you meant “a login page using our existing auth pattern with the StandardLayout component”?
4. Was the test coverage insufficient? Would a well-written integration test have caught this before merge?

Building the feedback loop

Every failure becomes an improvement:

• Context wrong → update the compaction docs or instructions file
• Guardrail missing → add a hook or extension (see Deterministic Enablement)
• Instruction unclear → add the clarification to your instructions file
• Test gap → add the test case to your suite

Over time, the agent gets structurally incapable of making the same mistake twice — not because the model got smarter, but because you built a system that catches and prevents the failure mode.

Remove the mental model

”AI sucks” is the most expensive conclusion you can reach. It stops you from doing the diagnostic work that actually makes AI productive.

Feedback Loops — The Engine Behind Everything

Everything in this blueprint is really about one thing — tightening feedback loops. The faster you learn that something is broken, the cheaper it is to fix.

There are three feedback loops in agentic development, and each one operates at a different speed.

Loop 1: Unit Tests (seconds)

This is the fastest loop. The agent writes code, runs tests, sees red, fixes the issue, and reruns. It happens inside the agent’s session with no human involved.

Your investment here is simple: write good tests. The agent uses them as real-time guardrails while it works.

Loop 2: CI/CD Pipeline (minutes)

This is the PR-level loop. The agent opens a PR, CI runs, something fails, and the agent comes back to fix it.

This is where the Copilot CLI extension model shines: it can pick up CI failures, read the logs, apply a fix, and rerun the pipeline without waiting on a human to babysit the loop.

Hector’s flow is straightforward: agent opens PR → CI runs → if it fails, the Copilot coding agent gets assigned back → it reads the error → it fixes → CI reruns.

Loop 3: User Feedback / Preview Review (hours to days)

This is the human-in-the-loop layer. The PR passes CI, deploys to a preview environment, and then a human reviews the actual experience.

Hector’s real workflow uses Vercel preview deployments. Every PR gets a preview URL. He reviews the preview on his phone. If something looks off, he comments on the PR, the agent reads the feedback, and it iterates.

This is the slowest loop, but it catches what tests cannot: UX issues, design drift, and business-logic mismatches that only show up when a human sees the result.

The hierarchy matters

• Catch everything you can at Loop 1 — it’s the fastest and cheapest loop.
• Catch integration issues at Loop 2.
• Catch high-level judgment issues at Loop 3.
• Never let a Loop 1 problem survive to Loop 3 — that’s pure waste.