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 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.

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

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.