Candor Labs

Each agent has a written scope document that lists exactly what it does and explicitly what it does not do. Scope is reviewed monthly.

Why: The support triage agent started including "suggested fix" in its issue categorizations. The founder found this helpful for the first two weeks. Then the agent suggested a fix for a race condition that involved refactoring the connection pool -- a change that would have broken 3 other features. The founder nearly implemented it on a Friday afternoon because "the agent already figured it out." The support agent's job is triage. Not diagnosis. Not code suggestions. That's the code review agent's job, and only on actual PRs with test coverage.

Failure mode: Agents gradually expand their output beyond their defined scope. "Helpful extras" become expected. The human starts relying on output the agent isn't qualified to produce.

Scope: All agents.

Agent output must be formatted for a single reviewer doing fast context switches. Maximum 5 items per summary. Priority labels on every item. No walls of text.

Why: The code review agent initially produced 800-word reviews covering every style violation, potential improvement, and design consideration. The founder started skimming after week 1 and skipping after week 2. A real bug (null pointer dereference in the auth flow) was buried on line 47 of a 62-line review alongside 11 style nits. The bug reached production. Two users hit it before the founder found it in the review he'd skipped.

Failure mode: Verbose output overwhelms a solo reviewer. Signal-to-noise ratio degrades. Critical items are buried in low-priority observations. The human adapts by reading less.

Scope: All agents.

The support triage agent categorizes issues (bug, feature request, question, duplicate) and assigns priority (P0-P3). It does not suggest fixes, workarounds, or implementation approaches.

Why: See C001. The support agent's "suggested fix" for the connection pool race condition was plausible but wrong. The deeper problem: once an agent provides code-level suggestions, the founder unconsciously treats the triage agent as a second code reviewer. But the triage agent has no access to the test suite, no awareness of the dependency graph, and no context about recent architectural decisions. Its suggestions are informed guesses, not engineering analysis.

Failure mode: Authority creep turns a triage agent into an unlicensed advisor. The human treats convenience as competence.

Scope: Support and triage agents.

The code review agent flags issues in PRs. It does not open PRs, push commits, create branches, or modify any code.

Why: Founding rule. The founder read about an AI code review tool that auto-fixed style violations by pushing commits to open PRs. A contributor's PR received 14 auto-fix commits that broke the contributor's code. The contributor abandoned the PR and left a comment: "I'll come back when your robot stops rewriting my code." For an open-source-adjacent dev tool at $12K MRR, contributor goodwill is existential.

Failure mode: Agents with write access to the codebase modify contributor work without consent. Contributors feel overridden. Open source community trust -- which feeds the commercial product's growth -- erodes.

Scope: Code review agent.

All three agents write to separate state files. The founder's morning check reads all three in a fixed 90-second ritual: support first (are users blocked?), code review second (are PRs waiting?), release notes third (is a changelog draft ready?).

Why: When agents posted to Slack individually, the founder was checking three channels plus his own notifications. Context-switching between agent outputs throughout the day fragmented his coding blocks. After consolidating into a single morning review, deep work blocks went from an average of 47 minutes to 2 hours 15 minutes (measured over 3 weeks via Toggl).

Failure mode: Distributed agent notifications fragment the solo founder's focus. Each interruption costs 15-25 minutes of re-immersion. Coding quality degrades.

Scope: All agents.

Agents do not communicate with each other. There is no inter-agent message bus. The founder is the sole coordinator.

Why: With 3 agents and 1 human, adding agent-to-agent communication creates complexity that exceeds the coordination benefit. The founder considered having the support triage agent send high-priority bugs to the code review agent for immediate analysis. But the founder IS the coordination layer. Adding a machine coordination layer when the human layer is a single person with full context creates a shadow decision-making process the founder can't audit in real time.

Failure mode: Agent-to-agent coordination at solo scale creates invisible workflows. The founder discovers decisions were made (or context was shared) without their knowledge. Control degrades.

Scope: All agents at solo founder scale.

The release notes agent generates from merged PR titles and descriptions only. It does not read code diffs to infer what changed.

Why: The release notes agent read a diff that renamed an internal function and generated a changelog entry: "Breaking: API endpoint /auth/refresh renamed." The function rename was internal only -- the API contract hadn't changed. A user on the changelog RSS feed opened a GitHub issue asking about the "breaking change" and whether they needed to update their integration. The founder spent 30 minutes clarifying that nothing had changed for users.

Failure mode: Agents infer user-facing changes from internal code diffs. Internal refactors are misrepresented as breaking changes. Users react to non-existent breaking changes.

Scope: Release notes and changelog agents.

The support triage agent checks for duplicate issues before categorizing. Duplicates are linked, not re-triaged independently.

Why: The same bug was reported 4 times across GitHub issues and Slack over a weekend. The triage agent created 4 separate P1 entries. The founder's Monday morning check showed 4 P1 issues and he panicked, thinking 4 different critical bugs had emerged. It was 1 bug reported 4 ways. After implementing deduplication (matching by error message, stack trace similarity, and affected endpoint), false P1 volume dropped 35% over the next month.

Failure mode: Duplicate reports are triaged independently, inflating priority counts. The single reviewer overestimates severity based on volume. Panic replaces triage.

Scope: Support triage agent.

When the code review agent cannot access a PR (private fork, permissions issue, deleted branch), it must report the failure, not skip the PR silently.

Why: A contributor opened a PR from a private fork. The code review agent couldn't access the fork's branch. It silently skipped the PR. The founder assumed "no review comments" meant the PR was clean. He merged it. The PR introduced a dependency with a known CVE. The code review agent would have flagged the dependency if it had been able to read the diff. Silent skip looked identical to clean review.

Failure mode: Access failures produce the same output as "nothing to report." The reviewer cannot distinguish between "reviewed and clean" and "not reviewed."

Scope: Code review agent, any agent with access-dependent workflows.

Linear task creation from agent triage requires the founder's approval. The triage agent drafts Linear tasks; it does not create them.

Why: The triage agent created 23 Linear tasks in its first week from GitHub issues and Slack messages. Seven were duplicates. Four were feature requests the founder had already decided against. Two were from the same user filing multiple reports about expected behavior. The founder spent 45 minutes cleaning up Linear -- longer than manual triage would have taken.

Failure mode: Automated task creation from unfiltered input fills the task system with noise. Cleanup takes longer than manual curation. The task system stops being trustworthy.

Scope: Any agent with project management tool write access.

Agent output quality must be measured against the time the founder saves, not the volume of output produced.

Why: The code review agent produced reviews for 100% of PRs. Impressive. But 70% of PRs were the founder's own code -- code he'd just written and already knew the issues with. The "time saved" on self-authored PRs was near zero. The agent was most valuable on contributor PRs (30% of volume) where the founder hadn't seen the code. We scoped the agent to contributor PRs only and saved the founder 20 minutes/day by eliminating the noise of reviewing his own reviews.

Failure mode: Agents optimize for coverage instead of value. Running on every input (including inputs the human already has context for) creates review overhead that exceeds the review benefit.

Scope: All agents at solo founder scale.

The founder reviews and approves every support response before it reaches a user. No auto-responses, even for FAQ-type questions.

Why: At $12K MRR with 340 users, every support interaction is a retention opportunity. The triage agent drafted a response to a user question about API rate limits: "Rate limits are documented at docs.candor.dev/limits." Technically correct but cold. The user was a $89/mo enterprise plan customer who was evaluating whether to expand to their team. The founder rewrote it as a personal message, offered a 15-minute call, and closed a $267/mo team plan upgrade. The auto-response would have answered the question and missed the expansion signal.

Failure mode: Efficient auto-responses miss relationship signals embedded in support interactions. Users with expansion intent receive transactional answers. Revenue opportunity is invisible to the agent.

Scope: Support triage agent.

No agent may label an issue as "won't fix" or "not a bug." Only the founder assigns terminal states.

Why: The triage agent categorized a user report as "not a bug -- expected behavior" based on the documentation. The user's point was that the expected behavior was confusing and should be redesigned. The founder agreed with the user. The agent's categorization would have closed a valid UX improvement because the agent couldn't distinguish between "works as documented" and "documentation reflects a poor design choice."

Failure mode: Agents apply terminal labels based on current system behavior. They cannot evaluate whether the current behavior should change. Valid improvement requests are closed as non-issues.

Scope: Support triage agent, issue management.

The code review agent includes a "confidence" indicator on each finding: HIGH (definite bug or security issue), MEDIUM (likely problem, needs human judgment), LOW (style preference, could go either way).

Why: Without confidence labels, the founder treated all code review findings equally. He either fixed everything (30 minutes on style nits) or skipped everything (missed real bugs). Confidence labels let him triage: fix all HIGHs immediately, review MEDIUMs during dedicated review time, batch LOWs for monthly style cleanup. Effective review time dropped from 25 minutes/day to 8 minutes/day with zero increase in bugs reaching production.

Failure mode: Uniform presentation of findings forces binary processing: everything or nothing. Confidence labels enable triage. Without them, the solo founder's limited review time is misallocated.

Scope: Code review agent.

Agents must never reference each other's output or claim awareness of what another agent said.

Why: The release notes agent once generated: "Fixed the race condition flagged in code review last week." No user cares about internal agent workflows. The changelog should say: "Fixed a race condition in connection pooling that could cause timeout errors under high concurrency." User-facing output should describe user-facing impact, not internal process.

Failure mode: Agents leak internal coordination details into user-facing output. Users receive information about the agency's internal process instead of information about what changed for them.

Scope: All agents producing user-facing content.

When the solo founder is unavailable for 24+ hours (vacation, illness), agents must queue output and pause any time-sensitive actions rather than accumulate unreviewed decisions.

Why: The founder took a 3-day weekend without pausing agents. He returned to 47 triaged issues, 12 code reviews, and 3 draft changelogs. The backlog took 2.5 hours to process. Worse, 2 P1 issues had been sitting in triage for 72 hours with users waiting for responses. The agents correctly triaged them as urgent but had no mechanism to escalate when the human wasn't responding. Now agents pause after 24 hours of no human interaction and send a single "review queue paused -- items waiting" notification.

Failure mode: Agents continue producing output when the solo human is unavailable. Backlog accumulates. Time-sensitive items age without escalation. The founder returns to a wall of decisions that should have been made 2 days ago.

Scope: All agents in solo-founder environments. ---