Agent experience is the new DX

Developer experience asks how well people can use your tools. Agent experience asks the same question about machines.

This page focuses on AI coding agents: tools like Claude Code, Cursor, and custom agentic workflows that write, run, and iterate on code with varying levels of human oversight. The same principles apply anywhere a model interacts with software or infrastructure on someone’s behalf.

Agent experience is a design discipline rather than a product category. It shows up in APIs, command line tools, documentation, permissions, environments, error messages, logs, and feedback systems. Most of those surfaces were originally designed for people.

Good developer experience shortens the distance between intent and a useful result. Humans benefit from visual hierarchy, progressive disclosure, readable explanations, and interfaces that support exploration.

Agents interact with the same systems differently. A dashboard designed for visual scanning may expose little usable information to a machine. A verbose error message may help a developer understand context while forcing an agent to spend tokens separating signal from noise. An interactive prompt can make a CLI easier for a person while stopping an automated workflow completely.

Designing for both consumers

Agent experience does not replace developer experience. Software systems increasingly serve both.

A developer may review a pull request in a visual interface while an agent retrieves the same change through an API. A developer may inspect a full build log while an agent requests only the failed step and relevant error. A person may prefer a guided setup flow while an agent needs a non-interactive command with predictable output.

Good tooling exposes the same underlying capabilities in forms appropriate to each consumer.

Developer tooling has spent decades assuming a person at the keyboard: someone who can scan a dashboard, notice something unexpected, look for more information, and resolve ambiguity using judgment.

Agents change the assumption. Source control systems, build infrastructure, package registries, cloud platforms, internal APIs, and developer tools increasingly receive requests from software acting on someone’s behalf.

Agents are becoming software users

Agents increasingly interact directly with the systems developers once operated manually.

They read documentation, call APIs, run commands, modify repositories, inspect logs, query infrastructure, and trigger workflows. Every interface along the path affects whether the agent can complete the task reliably.

Poor AX becomes human work

An agent handed a wall of unstructured output has to spend time and tokens determining what matters. An ambiguous API response can lead to an unnecessary retry or the wrong next action. An interactive prompt can stop an automated task and send it back to a person.

Problems accumulate across a workflow. A small amount of ambiguity at every step can turn an autonomous task into repeated clarification, review, and cleanup.

Better models do not eliminate interface design

Model capabilities will continue to improve. Teams have much more direct control over the systems models interact with: API schemas, documentation, CLI behavior, logs, permissions, environments, and feedback.

Better models can reason more effectively about poor interfaces, but stronger interfaces reduce how much reasoning is required in the first place.

Platform teams already do similar work for developers by creating paved paths through shared infrastructure. Agentic development introduces another user to design for.

Agent experience is a property of every surface an agent uses to complete a task.

For a coding agent, a single change might require reading documentation, querying a repository, running commands, modifying files, calling external tools, interpreting test output, checking CI status, and updating a pull request.

Getting the right context

Agents need access to information in forms they can retrieve and interpret predictably.

APIs benefit from stable schemas and structured responses. Documentation benefits from accurate examples, clear versioning, and canonical instructions. CLI tools benefit from machine-readable output modes. Tool descriptions benefit from precise names, inputs, outputs, and boundaries.

Protocols such as MCP make interface design especially visible. A tool description helps determine when an agent chooses a tool and how it constructs the request.

More available context does not automatically create better AX. Relevant context does.

Taking action safely

Agents need predictable ways to change a system.

Command line tools should support non-interactive execution, meaningful exit codes, and operations with clearly defined outcomes. Wherever practical, repeated commands should be safe or make duplicate actions obvious.

Permissions determine how much autonomy an agent can receive without expanding the cost of a mistake. Narrow scopes, approval boundaries, isolated environments, and policy enforcement can let agents perform useful work while limiting unintended effects.

Understanding what happened

An agent needs to know whether an action succeeded, failed, or produced an unexpected state.

Machine-readable status, specific errors, structured logs, and explicit state make the next step easier to determine. A useful error tells the agent what failed, where the failure occurred, and what the system expected.

Full detail should remain available when needed. It does not have to be the default response.

Finding state and history

Agents often need information a developer would normally retrieve by opening another interface.

Which deployment is currently running? Which pipeline failed? What changed after the previous attempt? Did the API call complete? Is a pull request already open?

Exposing operational state programmatically allows an agent to answer those questions without relying on a person to translate information from a dashboard.

Improving AX rarely requires rebuilding an entire platform around AI. Many of the highest-value changes make existing interfaces more explicit, structured, and predictable.

1. Return structured information

Offer machine-readable output for workflows an agent will use repeatedly.

For a CLI, this might mean JSON output against a documented schema. For an API, it means stable response types and explicit error states. For documentation, it means examples an agent can execute without reconstructing missing assumptions.

Human-readable output can remain available for people. Agents benefit from a machine-oriented path to the same information.

2. Curate context at the source

Return the information needed for the current decision rather than every piece of information available.

If three tests failed, identify the three failures and provide the relevant details before returning thousands of lines of unrelated output. If an operation fails because a parameter is invalid, identify the parameter and expected value directly.

Filtering at the source reduces token usage and narrows the number of plausible interpretations an agent has to consider.

3. Make actions predictable and repeatable

Agentic workflows frequently retry operations, branch into alternative approaches, and revisit previous steps.

Idempotent operations help make retries safe. Clear state transitions help an agent understand whether something already happened. Honest exit codes and explicit status prevent the agent from having to infer success from prose.

Guardrails should live in the system wherever possible. Permission boundaries and policy checks are more reliable than relying on every agent to discover and follow a written convention.

4. Treat latency as part of the interface

Feedback is most useful while the agent is still working on the task that produced it.

The acceptable latency depends on the workflow. A local syntax check may need to return almost immediately. A full integration test can take longer. A deployment may inherently require minutes.

The important question is whether the timing fits the decision the agent needs to make next.

5. Measure agent outcomes

Traditional UX metrics do not fully describe how well an agent interacts with a system.

Useful AX signals can include:

• How often the first attempt completes successfully
• How many retries or tool calls a task requires
• How much time or inference budget is required to reach a resolution
• How frequently a person has to intervene
• Which tools or interfaces most frequently precede failed attempts

A baseline makes it possible to distinguish a real improvement from a change that merely appears cleaner to a human reviewer.

Start with repeated failure

Pick a task your agents perform frequently and inspect unsuccessful attempts end to end.

Look for the first point where the agent lacked context, misunderstood state, selected the wrong tool, received ambiguous feedback, or required human intervention.

The most useful AX improvements often begin at a familiar software interface rather than inside the model itself.

AI agents are non-deterministic. Two attempts at the same task can produce different reasoning paths, tool sequences, and solutions.

Interface design can either increase or reduce the amount of variation those differences introduce.

Broad, noisy context
        ↓
More possible interpretations
        ↓
More variation in agent behavior

Curated, explicit context
        ↓
Narrower decision space
        ↓
More reliable action

An agent given an entire job log has many possible signals to follow. An agent given the relevant failure, affected file, expected behavior, and supporting context starts from a narrower problem definition.

The second interface does not make the model deterministic. It reduces unnecessary ambiguity.

Precise tool descriptions narrow tool selection. Stable schemas reduce interpretation. Explicit state reduces guessing. Well-defined permission boundaries limit available actions.

Good AX designs the surrounding system so model variability has less room to turn into incorrect or expensive behavior.

The principles above apply across the software stack. CircleCI focuses on one particular part of agent experience: how agents get useful validation feedback while they develop software, and how teams independently validate agent-generated changes before those changes ship.

Code generation is becoming faster and cheaper. Every additional change still needs evidence that it meets the standards required to merge and deploy.

CircleCI’s approach connects fast feedback inside the agent’s working loop with independent validation in CI.

A coding agent can produce a plausible change quickly. Evaluating the change can require considerably more work.

A passing test provides useful evidence, but it only tells you the checks you ran passed. A change can satisfy one test while introducing a regression elsewhere, solving the wrong problem, or failing another requirement the current test suite does not cover.

Agentic development increases the importance of both fast feedback and independent validation. Agents need enough signal to iterate efficiently while they are working, and teams need a broader validation layer before code becomes shared or deployable.

We use merge quality to describe whether a change has enough evidence behind it to meet the team’s requirements for merging, rather than treating a single passing signal as proof of correctness.

CI provides an independent place to collect and enforce that evidence.

Agentic software development operates across two feedback loops.

                INNER LOOP
      write → run → validate → fix
                    │
                    │ push / PR
                    ▼
                OUTER LOOP
      CI → deeper tests → policy
         → deploy → verify
                    │
                    │ structured feedback
                    └──────────────► agent

The inner loop

The inner loop is what happens while an agent is actively working on a change:

write → run → check → fix → repeat

The agent still has the problem, implementation, and recent tool output in its active context. Fast validation here helps catch problems before a push or pull request.

The outer loop

The outer loop begins when the change reaches shared delivery infrastructure.

It can include the CI/CD pipeline, integration and system tests, security checks, review, deployment, and post-deploy verification.

The outer loop serves a different purpose. Its results are shared across developers, agents, reviewers, and downstream systems. It provides independent evidence about a change outside the environment where the change was created.

Connect the loops

Strong agent experience keeps useful feedback flowing between them.

A failure caught during the inner loop can often be corrected immediately while the agent still has full working context. A failure found by CI should return to the agent with enough structured information to continue the task without rediscovering the entire problem.

The goal is not to move every outer-loop check into the inner loop. It is to make each loop good at its own job and make the handoff between them efficient.

Curation beats volume

Give agents the signal they need, with deeper detail available on demand.

A scoped failure report can be more useful than a complete job log, even though the log contains more information.

Green is not the bar

Passing checks provide evidence. Merge quality depends on the full set of requirements a team enforces.

Agentic development makes the distinction more important because generating another plausible implementation is cheap. Establishing enough confidence to ship it remains the harder problem.

Don’t merge the loops, connect them

The inner loop benefits from extremely fast, targeted feedback. The outer loop provides independent validation across a broader environment.

A better system moves the right validation closer to the agent while preserving CI as the shared validation layer, then returns outer-loop findings to the agent in a form it can use.

CircleCI is building agent-facing interfaces across both loops so agents can validate code earlier, receive higher-signal feedback from CI, and act on failures without forcing a developer to translate the results.

1. CI-grade validation in the inner loop

Chunk sidecars run targeted validation against impacted code in an isolated environment before the push.

The agent can validate working-directory changes while it still has the implementation in context, without waiting for the full CI pipeline. Sidecars are designed to return CI-grade feedback in under a minute for checks that belong in the inner loop.

Fast inner-loop validation catches straightforward problems closer to where they are introduced and leaves the outer loop focused on deeper shared checks.

2. Higher-signal validation in the outer loop

Smarter Testing uses test impact analysis to run the tests affected by a change, intelligently splits test execution across available compute, and can rerun failures to identify flakes.

Agentic development can increase the number of changes and validation cycles flowing through CI. Running the most relevant tests quickly helps keep feedback useful as volume grows.

Reducing flaky and unnecessary test execution also gives both agents and developers a clearer signal about whether a change requires attention.

3. Bring outer-loop failures back into context

A CI failure is most useful to an agent when the relevant information can return directly to its working environment.

The CircleCI CLI supports a --failure-report flag that distills a failed job into the information an agent needs to diagnose it without first parsing the complete log.

CircleCI also supports Fix with Claude Code, which sends a structured failure summary from a failed CircleCI run back to Claude Code in the terminal.

The outer loop detects the problem. The agent receives the relevant context, proposes a fix, and CI independently validates the next change.

4. Give agents direct access to CircleCI

The CircleCI CLI provides a machine-oriented interface to CircleCI with structured JSON output, failure reporting, pipeline operations, and deployment tooling.

The CircleCI MCP server exposes CircleCI tools directly to MCP-compatible agents. Agents can retrieve pipeline status, inspect failures and test results, rerun workflows, trigger pipelines, and perform other supported operations without requiring a developer to move information between systems manually.

For new projects, circleci onboard can inspect a repository, generate a starter CircleCI config, and connect the project to CircleCI.

Together, these interfaces let agents participate directly in the delivery workflow while CircleCI remains an independent validation layer around the code they produce.

Agent experience becomes easier to evaluate when an agent is working against a real repository, real tests, and real delivery infrastructure.

Connect a project to CircleCI, run your agent through a few development and validation cycles, and look closely at the handoffs: what context the agent receives, how quickly validation returns, and how much human translation is required when something fails.