Agent is blind - waits for feedback

"Agent is blind, waits for feedback" describes the L1 state where an AI coding agent completes its code changes, submits them, and then has no way to observe whether those changes

·CI pipeline exists but takes longer than 15 minutes
·Agents receive no real-time CI feedback (wait for full pipeline completion)

·CI runs on every PR (not just on manual trigger)
·Shared runner queue exists even if slow

Evidence

·CI pipeline configuration file in repository
·CI run duration logs showing median > 15 minutes

What It Is

"Agent is blind, waits for feedback" describes the L1 state where an AI coding agent completes its code changes, submits them, and then has no way to observe whether those changes are correct until a human delivers CI results to it. The agent cannot check CI status, cannot read test output, cannot see lint errors - it is entirely dependent on a human to relay the feedback loop. While it waits, it is blocked: it cannot iterate, cannot fix errors, cannot continue.

This problem has two distinct causes that are often conflated. The first is slow CI: even if the agent could check CI status, 18-minute CI means 18 minutes of waiting per iteration, which is prohibitively slow for useful agent work. The second is CI access: many agent configurations simply don't give the agent any mechanism to query CI results. The agent produces code, pushes it, and stops. A human must open the CI platform, read the results, and paste them back into the agent's context. The human becomes a manual relay between the agent and the feedback loop it needs.

The "blind" state is particularly damaging because agents without feedback cannot self-correct. An agent that wrote code that produces 3 lint errors could fix those errors in 30 seconds if it could see them. Instead, those errors appear in CI 15 minutes later, a human notices them, pastes the output to the agent, and the agent fixes them in 30 seconds. The human relay adds 15-20 minutes of overhead to a 30-second correction. At scale - an agent that makes 5 such corrections per task - this turns a 2.5-minute fix session into a 100-minute relay session.

At L1, the blind-agent pattern is universal because the infrastructure for agent-CI integration hasn't been built. Giving agents access to CI results requires CI API credentials, workflow orchestration, and agent prompting that explicitly tells the agent to check and act on CI feedback. These are not complex technical problems, but they require deliberate investment that most organizations at L1 haven't made.

Why It Matters

Agent self-correction is eliminated - agents that can't see CI results can't fix their own errors; every error requires human relay, multiplying the human time cost of each agent task
Human developers become manual message-passing systems - relaying CI output to agents is pure overhead that consumes developer attention and delays the agent's correction; it's busywork that should not exist
Agent iteration rate is bounded by human response time - when the human must relay each CI result, the agent iteration rate is limited to "how fast can a human check CI and paste results"; typically 1-3 iterations per hour
Agents cannot handle blocking errors autonomously - a blocked pipeline (compilation failure, missing dependency) that the agent could resolve in seconds instead sits until a human notices and intervenes
Developer perception of agents sours - developers who spend time relaying CI results to agents quickly conclude "this is more work than doing it myself" - the agent feels like a burden rather than a productivity tool

Getting Started

Give agents access to CI status via CLI - The fastest fix is granting agents access to the gh CLI (for GitHub Actions) or platform equivalents. Claude Code with shell access can run gh run list --branch $(git branch --show-current) --limit 1 to check the latest CI run status, and gh run view --log-failed to read failed job output. This requires no infrastructure changes beyond CLI access and appropriate permissions.
Add explicit CI-checking instructions to agent prompts - Update your agent system prompts to include: "After pushing changes, check CI status using [command]. If CI fails, read the failure output and fix the errors before reporting completion." Without explicit instructions, agents won't know to check CI even if they have access to the tools.
Grant CI API read permissions to agent credentials - For programmatic CI access, create a read-only CI API token and make it available in the agent's environment. GitHub Personal Access Tokens with repo scope allow reading workflow run status and logs. CircleCI API tokens support read-only project access. This enables the agent to check CI without full repository write permissions.
Implement a feedback injection step in your workflow - For workflows where the agent doesn't run interactively, implement a CI completion webhook that delivers results back to the agent's context. A GitHub Actions workflow that triggers on workflow_run completion and posts results to a Slack channel (which a developer relays to the agent) is a manual relay. A webhook that injects results directly into the agent's context window is the automated version.
Configure the agent to block on CI completion - After pushing changes, the agent should poll CI status until the run completes (not just starts), then read and process the results before reporting task completion. Polled completion is better than timed waits: while gh run list --json status | jq '.[0].status != "completed"' -e; do sleep 10; done waits until CI completes before continuing.
Measure and report agent iteration rate - Once agents can see CI results, measure the iteration rate: how many CI attempts does the average agent task require? This metric establishes the baseline that future CI speed improvements will improve. At L1, before CI access is fixed, this metric is unmeasurable because the human relay introduces variable delays that obscure the actual agent iteration rate.

Tip

The gh CLI is the fastest path to CI visibility for GitHub Actions users. Claude Code already supports shell tool use, and gh run view --log-failed returns the complete failure output for the most recent failed run in the current branch's context. Configure this as a standard step in agent instructions and most of the "blind agent" problem is resolved in an afternoon.

6 steps to get from here to the next level

Common Pitfalls

Giving agents CI access but not telling them to use it. Access without instruction doesn't help. Agents that can check CI but aren't told to check CI will not spontaneously discover this capability. Add explicit CI-checking steps to agent prompts: check CI after pushing, read failures, fix them. The capability must be paired with the instruction.

Granting excessive CI permissions to agent credentials. An agent that needs to read CI results only needs read access. Granting write access (ability to trigger runs, modify configurations, cancel jobs) gives agents more power than they need and increases the blast radius if an agent makes a mistake. Use the principle of least privilege: read-only CI API tokens for read-only CI access.

Building a feedback relay loop that requires constant human attention. Some teams implement "blind agent" mitigations by having developers monitor CI and manually paste results. This creates the worst outcome: the agent can now process CI results, but a human must still monitor and relay them. The relay should be automated. If the relay requires human attention, the agent is still blind; the feedback is just delayed instead of blocked entirely.

Conflating CI access with CI speed. Giving an agent access to CI results is necessary but not sufficient. An agent with CI access but 18-minute CI is no longer "blind" - it can see results - but it's "slow": waiting 18 minutes per iteration. Both problems must be addressed. CI access eliminates the relay overhead; CI speed eliminates the wait time. See the CI > 15 Minutes guide for the speed problem.

Not handling CI authentication expiration. Agent credentials (API tokens, GitHub Personal Access Tokens) expire. An agent that runs for 12 hours across multiple sessions on a task will hit token expiration at some point. Implement token refresh or use long-lived credentials (GitHub App tokens, service account tokens) that don't expire during typical agent session durations.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's developers have started using Claude Code for agent tasks, but the workflow is frustrating: after the agent pushes code, the developer has to manually check GitHub Actions, paste the failure output into the agent's context, and wait for the agent to fix it. This happens 3-5 times per task. The developer is essentially a human CI relay system, and it's consuming more developer time than the agent is saving.

Bob should make "agents can see CI results" a week-1 prerequisite for any AI agent rollout. The fix is simple: update the team's Claude Code instructions to include gh CLI usage for CI status checking, and verify that each developer's environment has gh authenticated with read access to the repository's Actions runs. Bob should run a 30-minute workshop showing the correct workflow: agent pushes, agent checks CI, agent reads failures, agent fixes failures, agent checks CI again until green. After the workshop, the human relay should disappear from normal agent workflows. Bob should follow up two weeks later to confirm the relay pattern is gone - if developers are still manually pasting CI results, the agent instructions weren't updated or the gh access wasn't granted.

SarahProductivity Lead

Sarah is trying to measure "agent task completion rate" - how often an agent completes a task without requiring human intervention. But she's finding that the metric is heavily confounded by the CI relay pattern: tasks that the agent could complete autonomously are being classified as "requiring human intervention" because humans must relay CI results, even though the intervention is pure infrastructure overhead rather than genuine task complexity.

Sarah should separate "human intervention to relay CI" from "human intervention to make a task decision" in her metrics. The former is an infrastructure failure (fixable by granting CI access); the latter is a genuine agent capability boundary. Once she separates these categories, she'll likely find that a large fraction of "agent needed help" events are actually "agent was blind to CI" events. That reclassification changes the improvement priority: instead of investing in more capable agents, invest in CI access infrastructure. Sarah should present this analysis to Bob with a clear recommendation: fix CI access first, then measure the true agent autonomy rate, and use that measurement to decide on further capability investments.

VictorStaff Engineer - AI Champion

Victor never experiences the "blind agent" problem because he set up comprehensive CI access for his Claude Code environment on day 1. His Claude Code CLAUDE.md includes instructions to use gh CLI to check CI after every push, and his shell environment has gh authenticated. He's running 4 parallel agents simultaneously, each checking their own CI status independently.

Victor should write up his Claude Code CLAUDE.md configuration and the shell environment setup as a team standard. The configuration is short - 10 lines in CLAUDE.md - but it completely eliminates the blind agent problem. Victor should also propose making this configuration part of the team's standard developer onboarding: every developer who sets up Claude Code follows the same CLAUDE.md template, which includes CI access setup. A 30-minute onboarding session that covers the CLAUDE.md template, gh authentication, and the agent CI workflow pattern would prevent the blind agent problem from occurring for every future new developer.