The Dogfooding Loop: Using the Product to Build the Product in an Autonomous Dev Org

When an AI agent files a bug, external trackers are dead ends — no machine-readable status transition, no automated follow-through. Filing bugs in the ITSM service being built closes the loop: ticket status transitions trigger automated task creation, and AI agents pick up the work. This paper documents the six components that make autonomous bug triage possible.

Executive Summary

External bug tracking tools are dead ends in autonomous development organizations. When an AI agent discovers a bug and files a report in an external system, the ticket is created — and nothing automated happens next. No machine-readable status transition exists, no webhook fires into the build system, and no task is automatically created. In a human-staffed team, a human reads the report and takes action. In an autonomous development organization, no human is watching the external tracker. This paper examines the decision to replace external bug tracking with the ITSM service under active development, and documents the six implementation components required to close the loop: CRM setup, service account provisioning, a unified bug-filing script, CI integration, workflow automation, and an action executor. The result is a fully connected cycle in which an AI agent files a bug, a human triage decision transitions the ticket to “Accepted,” a workflow trigger creates a project task, and a second AI agent picks up and resolves the task — with no human intervention after the initial acceptance decision.

---

Key Findings

• External bug tracking tools are dead ends in autonomous development organizations: tickets are created but no automated action follows, because no machine-readable status transition is wired to the build system, and no autonomous process monitors the external tracker for new work.
• Filing bugs in the product being built is a validation strategy, not merely a tool migration: it surfaces failure modes under real conditions — time pressure, real data, real consequences — that testing against mocks cannot discover.
• Separating the filing identity from the execution identity in automated workflows produces an audit trail that remains readable when all participants are AI agents: the ticket records who filed, who accepted, and who resolved, even when all three are automated processes using distinct credentials.
• The nightly acceptance test suite filing bugs against the ITSM service itself creates a recursive quality signal: regression in the ITSM service appears as a spike in its own bug queue, providing a real-time indicator that requires no additional monitoring instrumentation.
• Workflow automation that triggers on ticket status transitions eliminates the human step between “bug reported” and “task created”: once a human accepts a ticket, the remainder of the triage-to-resolution cycle executes autonomously.

---

1. External Bug Trackers Are Dead Ends in Autonomous Organizations Because No Automated Action Follows Ticket Creation

External bug tracking tools fail autonomous development organizations at the handoff point. The failure is not in ticket creation — AI agents can call a REST API. The failure is in what happens after the ticket is created: nothing, automatically.

In an external tracker, a ticket in “New” status sits until a human reads it, evaluates it, and takes action. That action — creating a task, assigning a developer, scheduling a sprint — is performed by the human. The tracker does not perform it. In a human-staffed organization, the human is the automation. The tracker is a shared memory system for coordinating human attention.

An autonomous development organization has no human watching the tracker. An AI agent can create a ticket. It cannot, with an external tracker, cause a downstream task to be created when a human accepts that ticket. The status transition from “New” to “Accepted” occurs in a system that has no outbound integration with the build system, no webhook into the task queue, and no way to signal the executor agents that new work is available.

The ticket is filed into a void.

Dimension	External Tracker	Internal ITSM Service
Ticket creation	Available	Available
Status transition webhooks	Not wired to build system	Configurable, wired to action executor
Automated task creation on acceptance	None	Triggered by workflow rule
Filing identity traceable to build system	No	Yes — service account linked to CRM contact
Audit trail readable by agents	No	Yes — ticket ID, filing identity, resolution identity
Validation signal for the product	None	Bug queue is a quality metric
Human dependency after triage	Ongoing	Single decision point (acceptance)

The table above captures the asymmetry. An external tracker is operationally adequate for human-staffed teams, where the human provides the integration between the tracker and the development workflow. Remove the human from that loop and the tracker becomes a write-only store with no consumers.

The solution is not to find a better external tracker. The solution is to use the ITSM service that the team is already building — and to build it so that the autonomous development organization can use it to manage itself.

---

2. Filing Bugs in the Product Being Built Is a Validation Strategy, Not a Tool Migration

The decision to file bugs in the internal ITSM service rather than an external tracker is a validation strategy. The framing as “tool migration” is technically accurate but misses the purpose.

When a development team uses its own product under real conditions — real data, real time pressure, real consequences for failures — it discovers failure modes that no test suite surfaces. A test suite runs against a mock or a known fixture. Dogfooding runs against the live system, at the moment that a CI pipeline is failing and an accurate bug report is operationally necessary.

The validation surface expands in proportion to use. Every bug filed through the ITSM service is a real transaction through the ticket creation API, the attachment upload endpoint, and the workflow evaluation engine. Every status transition is a real trigger evaluation. Every task created by the workflow is a real write to the project management service. No synthetic load test produces the same coverage, because synthetic tests do not discover the interactions between real data, real timing, and real system state.

The recursive case is the strongest form of this argument. When the ITSM service has a bug in its own ticket creation endpoint, and the nightly acceptance test suite catches it, the test suite files a bug report — in the ITSM service. The bug queue of the ITSM service contains a ticket reporting a defect in the ITSM service. The team is forced to use the defective system to manage the repair of the defective system. Any usability failure, any workflow gap, any missing feature that makes triage harder — all of these manifest immediately, with full urgency.

The recursive filing case — filing bugs in the bug-filing system — creates a dependency risk: if the ITSM ticket creation endpoint is itself broken, the bug report for that breakage cannot be filed through the standard path. The CI pipeline must include a fallback reporting path (direct notification, log file, or secondary channel) for cases where the primary ITSM filing fails. Without this fallback, a critical regression in the ITSM service silently suppresses its own bug report.

The migration also imposes productive constraint. Moving from an external tracker to the internal ITSM requires that the internal ITSM have sufficient feature parity for the team to operate without constant reversion to the external tool. The definition of “sufficient parity” is not determined by a planning document — it is determined by the bugs filed during the migration. Features that the team actually needs surface as ITSM tickets. Features that the team thought it needed but does not are never requested. The migration process is self-prioritizing.

---

3. Six Components Work Together to Close the Loop Between Bug Discovery and Autonomous Resolution

3.1 CRM Setup

The CRM contains an Account record representing the organization and a Founder contact linked to that account. AI agents filing bug reports do so on behalf of the Founder contact — not as anonymous API calls, and not as a generic system user.

This matters because ITSM workflows are contact-aware. A ticket filed by the Founder contact routes through the same triage workflow as a ticket filed by an enterprise customer. The filing identity participates in the workflow, not just in the audit log. When a human triages the ticket, they see a reporter with a contact record, a linked account, and a history of previous tickets. The triage context is complete.

The Founder contact also provides the social proof layer for the dogfooding signal: when the Founder is the most active reporter of bugs in the ITSM service, that is a visible organizational commitment to using the product.

3.2 Service Account

Vault stores the platform credentials used by AI agents for ITSM ticket creation and attachment upload. These credentials are scoped to the minimum required permissions: create ticket, upload attachment, and read ticket status. They cannot close tickets, modify workflow rules, or access other customers’ data. The scope is intentionally minimal — exactly four permissions: itsm:tickets:create, itsm:tickets:read, itsm:comments:create, and itsm:attachments:create. No write access to existing tickets, no admin permissions. The minimal scope means a compromised credential cannot close, reassign, or delete existing tickets — only create new ones.

The service account identity is distinct from the Founder contact identity in the CRM. The Founder contact is the reporter recorded on the ticket. The service account is the authentication credential used to make the API call. This separation is architectural — it means that the audit trail shows the human-meaningful identity (Founder) on the ticket, while the system logs show the machine identity (service account) in the API access log. Both are traceable. Neither is ambiguous.

AI agents do not use personal user accounts. Personal accounts create attribution ambiguity when automated actions are interleaved with human actions in the same account’s activity history. Service accounts make automated actions unambiguously identifiable.

3.3 The Bug-Filing Script

report-bug.sh is the single interface for all bug reports, regardless of origin. The CI pipeline uses it. AI agents use it. A human developer who wants to file a bug through the standard path uses it.

#!/usr/bin/env bash
# report-bug.sh — file a bug in the ITSM service
# Usage: report-bug.sh --product PRODUCT --feature FEATURE \
#          --subject SUBJECT --body BODY [--screenshot PATH ...]

set -euo pipefail

PRODUCT=""
FEATURE=""
SUBJECT=""
BODY=""
SCREENSHOTS=()

while [[ $# -gt 0 ]]; do
  case "$1" in
    --product)    PRODUCT="$2";      shift 2 ;;
    --feature)    FEATURE="$2";      shift 2 ;;
    --subject)    SUBJECT="$2";      shift 2 ;;
    --body)       BODY="$2";         shift 2 ;;
    --screenshot) SCREENSHOTS+=("$2"); shift 2 ;;
    *) echo "Unknown argument: $1" >&2; exit 1 ;;
  esac
done

# Create the ticket
TICKET_ID=$(curl -sf -X POST "${ITSM_BASE_URL}/api/v1/tickets" \
  -H "Authorization: Bearer ${ITSM_SERVICE_ACCOUNT_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "$(jq -n \
    --arg product  "$PRODUCT" \
    --arg feature  "$FEATURE" \
    --arg subject  "$SUBJECT" \
    --arg body     "$BODY" \
    --arg reporter "${CRM_FOUNDER_CONTACT_ID}" \
    '{product: $product, feature: $feature, subject: $subject,
      description: $body, reporter_contact_id: $reporter}')" \
  | jq -r '.id')

echo "Filed ticket: ${TICKET_ID}"

# Attach screenshots if provided
for SCREENSHOT in "${SCREENSHOTS[@]}"; do
  curl -sf -X POST "${ITSM_BASE_URL}/api/v1/tickets/${TICKET_ID}/attachments" \
    -H "Authorization: Bearer ${ITSM_SERVICE_ACCOUNT_TOKEN}" \
    -F "file=@${SCREENSHOT}" \
    -F "filename=$(basename "${SCREENSHOT}")" \
    > /dev/null
  echo "Attached: ${SCREENSHOT}"
done

The script accepts an optional --screenshot flag that attaches a Playwright screenshot via multipart POST to the ticket attachments endpoint — the same attachment mechanism used for any other file. The script is also designed to exit 0 and log a warning when the ITSM API is unreachable, rather than failing the calling process. CI runs must not be blocked by ITSM unavailability: the test results are the primary artifact, and the bug report is secondary.

The script’s value is in standardization. A bug filed by a CI pipeline and a bug filed by an AI agent arrive in the ITSM service with identical structure, identical reporter identity, and identical attachment handling. The triage workflow does not need to distinguish source — it processes every ticket the same way.

The --screenshot parameter exists because AI agents operating in browser automation contexts regularly capture screenshots as evidence. A bug report that includes a screenshot of the failed UI state requires no additional investigation by the human triaging the ticket — the failure is visually documented. The attachment upload step is optional; the ticket is created regardless of whether screenshots are provided.

3.4 CI Integration

The nightly acceptance test suite is updated to call report-bug.sh on test failure rather than writing to a log file or emailing a notification address. Each failing test produces one ITSM ticket.

The ticket body includes the test name, the assertion that failed, the expected value, the actual value, and the full stack trace. The product and feature fields are derived from the test module path — a test in acceptance/itsm/ticket-creation/ files against product itsm and feature ticket-creation. No manual categorization is required.

This integration means that the human performing morning triage sees a fully categorized bug queue that was populated overnight by automated testing, with each ticket containing enough detail to make an acceptance decision without further investigation in most cases.

3.5 Workflow Automation

The ITSM service includes a workflow engine that evaluates rules on ticket status transitions. The rule relevant to the autonomous development loop:

# workflow-rule: accepted-ticket-creates-task.yaml
trigger:
  event: ticket.status_changed
  conditions:
    - field: status
      from: new
      to: accepted

actions:
  - type: create_project_task
    target_service: project-management
    task:
      title: "Fix: {{ ticket.subject }}"
      description: |
        Ticket: {{ ticket.id }}
        Product: {{ ticket.product }}
        Feature: {{ ticket.feature }}

        {{ ticket.description }}
      labels:
        - bug
        - source:itsm
      metadata:
        itsm_ticket_id: "{{ ticket.id }}"

When a human triages a ticket and sets the status to “Accepted,” this rule fires. The action executor receives the trigger event and creates a project task in the sprint backlog. The task inherits the ticket subject, the full ticket description, and a reference back to the originating ticket ID.

The human has made one decision: this bug is real and worth fixing. Everything after that decision is automated.

3.6 Action Executor

The action executor is the backend service that receives workflow trigger events and performs the external API calls the workflow rule specifies. Without it, the workflow trigger fires and is consumed — the event is acknowledged — but no project task is created.

The executor is a stateless consumer of a workflow event queue. It receives an event, reads the action specification from the event payload, calls the project management service API to create the task, and publishes a completion event back to the ITSM service so the ticket’s activity log records that a task was created.

The executor’s design must be idempotent. If the workflow engine retries a trigger event due to a transient failure, the executor must not create duplicate tasks. The idempotency key is the combination of the ticket ID and the trigger event ID — if a task already exists in the project management service with that combination, the executor returns success without creating a new task.

---

4. Separating Filing, Triage, and Execution Identities Produces Audit Trails Readable When All Participants Are Automated

The bug-reporting loop involves three distinct identities: the filing identity, the triage identity, and the execution identity. Each is separate. Each is traceable.

Filing identity is the Founder contact in the CRM, recorded as the reporter on every ITSM ticket filed by an AI agent or by the CI pipeline. The filing identity is human-meaningful — it appears in the ticket UI, in triage views, and in reports. When a senior engineer reviews the bug queue, they see “reported by Founder” and understand the organizational context.

Triage identity is the human (or senior AI agent) who changes the ticket status to “Accepted.” This identity is recorded in the ticket’s activity log as the user who performed the status transition.

Execution identity is the AI agent role assigned to the project task created by the workflow trigger. The project task carries an assignee — the agent responsible for resolving the bug — and that assignee’s activity on the task (comments, status changes, linked commits) is separately recorded.

The audit trail produced by this architecture answers four questions without ambiguity: Who reported the bug? When? Who accepted it? Who resolved it? In a fully automated loop where the answer to all four might be non-human processes, the audit trail remains readable because each step uses a distinct, named identity.

The credential separation also enforces least privilege. The service account used for filing (ITSM_SERVICE_ACCOUNT_TOKEN in the script) has no ability to accept tickets or create project tasks. The action executor uses a separate service account scoped to project task creation. A compromised filing credential cannot manipulate the workflow or create unauthorized tasks.

---

5. The ITSM Service Filing Bugs Against Itself Creates a Recursive Quality Signal for Detecting Operational Regression

The most operationally useful property of dogfooding is the recursive quality signal it produces.

When the nightly acceptance test suite runs tests against the ITSM service and some tests fail, report-bug.sh files those failures as ITSM tickets. The ITSM service’s own bug queue receives tickets reporting defects in the ITSM service. The spike is visible immediately, at the start of the next business day, before any engineer has looked at a dashboard or run a query.

This recursive signal has several properties that make it superior to conventional monitoring:

First, it is always proportional to actual defect density. A spike in the ITSM service’s own bug queue means tests are failing — not that a metric crossed a threshold, and not that an alert rule was triggered. The tickets are the evidence, not an indicator that evidence might exist elsewhere.

Second, it is automatically categorized. Each ticket carries the product and feature fields populated from the test module path. A spike in tickets for product: itsm, feature: workflow-engine points directly at the regression site without log triage.

Third, it is self-documenting. The ticket body contains the full failure context — assertion, expected value, actual value, stack trace. The on-call engineer who picks up the ticket has sufficient information to reproduce the failure without querying logs or re-running tests manually.

The recursive signal depends on the acceptance test suite covering the ITSM service itself. If the test suite is incomplete — covering only the happy path for ticket creation, for example — then a regression in the attachment upload endpoint or the workflow evaluation engine will not produce tickets. Coverage of the ITSM service’s own API in the acceptance test suite is the prerequisite for the recursive signal to function. Prioritize test coverage of the components involved in the bug-reporting loop itself: ticket creation, status transitions, and workflow trigger evaluation.

---

6. Parity Requirements Emerge Through Use, Not Planning — File Bugs to Discover What Is Missing

Migrating from an external tracker to the internal ITSM service is not a project with a defined completion date. It is a continuous process of discovering what parity actually requires.

The planning-first approach to migration produces a requirements document that lists every feature the team believes it uses in the external tracker. That document is inevitably incomplete: it reflects conscious use, not habitual use. Teams rely on features they do not think to list, and those features surface only when they are absent under operational conditions.

The use-first approach is different. Begin filing bugs in the internal ITSM service before it reaches full parity. File the bugs that arise from the migration itself in the ITSM service. The gap between what the team needs and what the ITSM service provides appears as tickets in the ITSM service’s own queue — prioritized by actual frequency of need, documented with actual failure context, and visible to the same triage and execution workflow that handles all other bugs.

The migration is complete not when a checklist is satisfied but when the team stops reverting to the external tracker. That threshold is observable: the external tracker stops receiving new tickets. The transition date is implicit, not declared.

This approach also avoids the sunk-cost trap of full parity before migration. A team that waits for full parity before switching never switches, because full parity is a moving target — the external tracker continues to evolve during the migration planning period. Switching before full parity forces the team to accept some inconvenience in exchange for continuous validation signal and forward momentum.

---

7. Recommendations for Implementing Autonomous Bug-Reporting Loops

1. Replace your external bug tracker with the ITSM service as soon as the ticket creation endpoint is stable. Do not wait for full parity. Begin filing real bugs in the real system and let the bug queue define what parity requires.

2. Create a dedicated service account for all automated bug filing in your organization. Do not reuse personal credentials or a shared admin account. The service account makes automated actions unambiguously identifiable in access logs and audit trails, which is essential when debugging integration failures.

3. Define a CRM contact as the reporter identity for all AI-filed tickets in your system. Anonymous tickets or generic-system-user tickets are harder to triage and harder to route. A named CRM contact provides triage context and participates correctly in any contact-based routing rules.

4. Implement report-bug.sh as the single interface for all bug reports in your pipeline before integrating CI. Standardize the interface first. Once the script is stable, integrating the nightly test suite is a one-line change per test failure handler.

5. Instrument your CI integration to fail gracefully when the ITSM service is unavailable. The nightly acceptance test suite must not itself fail due to an ITSM filing error — the test results are more important than the bug report. File to a fallback log when the ITSM API returns an error, and retry filing at the next available opportunity.

6. Verify your action executor’s idempotency in staging before enabling the workflow trigger in production. Fire the same trigger event twice against the executor in a staging environment before enabling it in production. A non-idempotent executor creates duplicate project tasks, which pollutes the sprint backlog and requires manual cleanup.

7. Monitor your ITSM service’s own bug queue as a primary quality dashboard. A spike in tickets against the ITSM product is an early regression indicator. Configure the triage view to surface same-product tickets prominently during the period immediately following a deployment.

---

Conclusion

The dogfooding loop is not a process optimization — it is a structural requirement for autonomous development organizations that need to close the gap between bug discovery and bug resolution without continuous human intervention.

External trackers cannot close this loop. They receive tickets and hold them, waiting for a human to read them and act. In organizations where human attention is the scarce resource being replaced by autonomous agents, that dependency is the bottleneck. The ITSM service built by the team, wired to the project management service through workflow triggers, removes the bottleneck at the point that matters: the transition from “bug accepted” to “task ready for execution.”

The six components documented here — CRM setup, service account, unified filing script, CI integration, workflow automation, and action executor — are individually straightforward. Each is a single-purpose component doing a well-defined job. The architectural insight is in their combination: together, they produce a cycle that runs end-to-end on a single human decision, with every other step performed by automated processes using traceable identities.

As autonomous development organizations mature and take on longer-horizon work, the patterns documented here will become standard infrastructure expectations rather than innovations. The teams that establish these patterns early will accumulate validation signal, audit trail depth, and workflow reliability that late adopters will need to reconstruct from scratch. The dogfooding loop is most valuable not at first use, but after months of continuous operation — when the ITSM service’s own bug queue has become a rich historical record of the product’s evolution, filed, triaged, and resolved by the organization that built it.

---

Code examples are sanitized and generalized. No proprietary information is shared. Opinions are my own and do not reflect my employer’s views.