We Built a Discord-to-PR Engineering Agent: Architecture, Coordination, and Evidence

A Discord report can be one screenshot and one sentence. Resolving it still means recovering context, finding the right repository, avoiding duplicate work, testing the current revision, and returning proof to the reporter.

Why we built it

At VoicePing , the multilingual virtual office helps distributed teams talk in real time, while Meeting Logs preserve decisions as searchable, governed records. But when a conversation becomes an engineering report, a person still has to carry it from Discord to the right codebase and back again.

We wanted an autonomous engineering agent to own that loop. We gave a coding agent Discord, Git, terminal, test, and browser access. It could write code, but it could not reliably answer: Does this report already have an owner? Is this evidence current? Did another task use the same client? Who may approve the result?

A bot reacts to one event. A dependable developer owns a problem across many events: a duplicate report, new thread context, a moving target branch, a failed test, or missing client access. We did not need another code generator. We needed a system that could preserve ownership, context, and proof over time.

The result: one report, one case, one reviewable handoff

The prototype turns a report into a durable case, gives that case one persistent coding task, isolates the change, validates the current revision, and returns a structured evidence receipt. It then stops at a human decision.

Discord report or product feedback → durable case → persistent coding task → isolated worktree → build and client validation → evidence receipt → PR-ready result → human review.

The result is not an auto-merge bot. It is a harness that makes duplicate work, stale proof, shared-client conflicts, and missing approval visible. Humans report and decide; agents engineer; deterministic controls preserve identity and gates. The results below are prototype evidence, not a production benchmark or ROI claim.

The workflow spans three operational planes. The control plane owns identity, policy, permissions, and task mapping. The worker plane owns diagnosis, isolated code, and checks. The evidence plane owns client access, proof, privacy review, and delivery.

The coordinator discovers and dispatches; it does not modify application code. Workers can be replaced because the durable case, rather than a worker transcript, is the system of record. The Monitor agent observes live work and surfaces gaps, but it cannot take over intake, code, or approval.

First, turn the report into a case

A report is an event, not yet an engineering task. It may be a regression, product feedback, a duplicate, a permission problem, or private customer context that should never enter a coding session. Before dispatch, the system preserves the source, classifies the request, links any existing case, and records the next owner.

Direct reports and product feedback need different states. A reproducible regression may be ready for engineering. Feedback may need product judgment, duplicate an existing request, or contain customer information that requires a narrower privacy boundary.

VoicePing had already treated Discord as an operational surface for voice transcription and time-tracking updates . This agent loop uses it differently: Discord is the intake and delivery surface, while the durable case ledger remains the engineering source of truth.

A sanitized five-week snapshot of our private product-feedback channel contained 69 messages: 32 automated intake records, 37 human messages, 19 explicit replies, 27 messages with reactions, and 13 attachments. Only 15 of 32 automated records had an explicit reply or reaction in the captured channel. An “eyes” reaction may mean seen; it cannot safely mean owned, accepted, or fixed. That is why feedback stays a product case until a human makes it actionable.

The same traceability principle applies to product-feedback analysis: every claim should stay connected to its source material. In the engineering harness, however, analysis does not authorize a code change; a human must first make the case actionable.

The coordinator maintains two identities. Exact source identity records each Discord message once. Semantic case identity links separate reports that may share one root cause. Exact matching prevents replay; semantic matching prevents parallel fixes for the same problem.

Low-confidence matches remain reviewable. The system never silently discards a report, and it does not convert feedback into an engineering prompt until the environment, expected and actual behavior, impact, evidence, privacy scope, and owner are sufficiently clear. A final receipt returns to every linked source conversation, not only the most recent message.

Scheduling: a clock wakes the coordinator, identity chooses the work

An hourly schedule is useful, but a clock has no memory. Each pass must fetch only the Discord delta, reject bot progress as new intake, apply exact deduplication, attempt semantic linking, and then choose one outcome for each source: skip a known item, resume its open case, or start one new case.

A clock answers when to run; coordination answers whether the work already exists and what done means. The persistent task ID prevents a later run from rediscovering the repository and proposing a second fix. Delivery is idempotent too: acknowledgments, blockers, and results stay in the source thread, and the coordinator refetches Discord before retrying an ambiguous post.

OpenAI Codex Scheduled tasks provide recurring local execution, isolated worktrees, unattended sandbox controls, and standalone or conversation-attached tasks. The Codex app announcement also describes parallel agents and built-in worktree support.

VoicePing uses that functionality as the clock and worker runtime. The custom coordinator owns Discord discovery, case identity, semantic deduplication, persistent task mapping, shared-client leases, privacy policy, completion gates, and delivery receipts. Codex Scheduled tasks start execution; they do not replace the workflow-specific control plane.

Durable memory: one case, one task, current proof

Scheduled runs can stop and workers can restart, so the durable record must survive both. One case links the immutable source, semantic classification, owner, persistent task ID, worktree, target revision, checks, capture, private artifacts, receipt, and terminal status.

One case should have one active task, and every proof artifact should name the revision it proves. This makes a resumed worker useful immediately: it can compare the recorded state with the current branch instead of reconstructing ownership from chat history. If the branch moved after a passing run, the old proof remains historical evidence but no longer satisfies the completion gate.

This is the broader lesson in OpenAI’s harness-engineering write-up and Cursor’s cloud-agent notes : durable execution and feedback loops are part of the product, not incidental plumbing.

Keep the task moving without replacing the ledger

OpenAI describes /goal as a durable objective that continues across turns toward a verifiable stopping condition. That maps naturally to one engineering case: code the smallest safe change, pass focused and surrounding checks, exercise the affected client, and return usable proof.

The reviewed prototype histories use persistent task IDs plus the external case ledger; they do not show /goal closing cases today. A per-issue goal is the next execution layer, not a retroactive description of the prototype. The goal can guide work, while the ledger remains authoritative for source identity, artifacts, receipts, and terminal state.

The Monitor agent provides a separate supervision loop. A higher-frequency heartbeat rebuilds the live set from non-terminal cases and deep-reads only a task that is new, changed, stale despite an autonomous next step, or missing completion evidence. It may steer a concrete blocker, stale assumption, incorrect status, or missing gate; otherwise it stays quiet.

Monitoring improves both the active case and the harness, without granting self-modification. Repeated process gaps become human-reviewed improvement candidates. The Monitor cannot fetch intake, create a duplicate task, engineer the fix, bypass approval, or rewrite its own operating rules.

Execution: isolate code and pin model routing

Once identity is stable, execution can run in parallel. Each actionable case gets one scoped worktree, and a resumed worker compares its change with the current target revision. The harness also removes another moving variable by pinning normal work to one model-and-effort route rather than allowing agents to choose ad hoc.

OpenAI Codex GPT-5.6 Sol at xhigh is the baseline for the coordinator, issue task, bounded subagents, and Monitor agent. Ordinary work is not routed to Terra or Luna, and ultra is disallowed. This is an operating choice, not a claim of universal optimality; see OpenAI’s GPT-5.6 model announcement .

Anthropic Claude Fable 5 at max is allowed once, from a clean worktree, only after two distinct causal attempts fail the same focused check. It returns a candidate to the normal privacy, test, client, evidence, and review gates. It cannot solve missing permissions, signing, fixtures, devices, or a busy shared resource.

Worktrees isolate files, not the shared client

Git worktrees prevent agents from overwriting one another’s code, but they do not isolate a signed-in browser, desktop client, simulator, recorder, or playback device. Two agents can click the same UI and both produce convincing-looking evidence for the wrong interaction. The harness therefore serializes only the scarce client phase.

The shared UI lease is cross-cutting, not a stage that every task holds from start to finish. A task acquires it immediately before a client action, rechecks ownership before each click or capture, and releases it after that phase. Code analysis and tests continue in parallel.

The lease record binds the resource to one task, case, expiry, and capture identity. That metadata makes the screenshot or recording auditable and stops a later cleanup lease from being presented as proof for an earlier action.

Validation: prove four different claims

A green test suite is necessary, but it proves only that selected code paths passed. It does not prove that the target revision is current, the reported client behavior works, the correct window was captured, or the evidence is safe to share. As Anthropic’s agent-evaluation guide also emphasizes, a successful transcript is not necessarily a successful outcome.

The agent cannot finish with “tests pass.” Completion requires four independent claims:

1. formatting, linting, type checks, focused tests, regressions, and build pass;
2. the change and results belong to the current target revision;
3. the affected web, desktop, or mobile client is exercised;
4. reviewed evidence is privacy-safe, durable, and confirmed in the source thread.

Those claims are returned as a receipt rather than a transcript. The reviewer should be able to see the outcome, revision, checks, client flow, evidence references, residual risk, and requested human action without replaying the agent’s internal conversation.

Evidence is reviewed for behavior and privacy, written to private Cloudflare R2 storage, read back by hash, and delivered to the originating thread. Raw Discord content, credentials, customer context, and unreviewed artifacts remain private. Repository access is scoped, and production inspection is read-only.

If code passes but client evidence is blocked, the truthful result is “implemented; client verification blocked.” PR-ready never means self-merged. A human reviews the diff, proof, privacy boundary, and deployment risk, then approves, requests a revision, or rejects the change.

What failed, and what the prototype actually proved

The most useful guardrails were the ones that rejected plausible-looking success. We observed a merged fix becoming stale after later code changes, tests passing while the reported interaction remained untested, a recording showing the wrong foreground window, and a UI lease expiring during capture. Authentication, roles, signing, devices, timeouts, and ambiguous Discord delivery also produced blockers that another model call could not remove.

These failures matter because they are coordination and evidence failures, not simply model-quality failures. A stronger solver cannot make an old screenshot current, create missing device access, or safely resend an ambiguous message.

We verified two narrow snapshots. One early coordinator revision completed 32 automated tests plus compile and privacy checks. A later audit reviewed six engineering tasks against stricter end-to-end gates; zero of six had enough current-client proof to qualify as complete.

The two snapshots answer different questions. The first shows that coordinator control logic had automated coverage. The second shows that passing code checks did not yet satisfy a strict current-client completion contract. Neither establishes production reliability, general coding accuracy, cost savings, or ROI.

The counts remain sanitized prototype evidence rather than a benchmark. The two cases below use only the privacy-reviewed proof that was deliberately returned to each source thread. Related VoicePing engineering notes describe production constraints in real-time bilingual Whisper and a Go WebSocket proxy rewrite .

Real task and outcome

Two cases show the same loop: acknowledgement, engineering state changes, and a verified result returned to the source thread. The receipts below use only the supplied thread screenshots, prepared for the page without cropping.

Build the harness or buy a managed coding agent?

Managed services already provide much of the worker runtime. Examples include Devin , GitHub Copilot’s cloud agent , Cursor Background Agents , Google Jules , and OpenAI Codex cloud . Capabilities, pricing, and security terms change, so the useful comparison is the workflow boundary, not a permanent product ranking.

Buying usually wins on setup time and maintenance burden. A managed service is a strong fit when the workflow already resembles issue → branch → tests → pull request and the vendor’s privacy, reliability, review controls, and cost model fit the organization.

Building wins when custom Discord integration, semantic case identity, product feedback states, data locality, shared-client locking, or evidence provenance are core requirements. It offers deeper workflow control and lower vendor lock-in, but the team owns coordinator reliability, observability, maintenance, and capacity planning.

The practical answer can be hybrid: own the case and evidence contract, buy the coding runtime. Immutable case context goes to the worker; structured status, revision, checks, blockers, and evidence references come back. Human approval stays outside both systems.

What we measure next

The next evaluation should measure the whole loop with explicit denominators and sampling windows, not only whether a model produced a patch.

The leading indicators are duplicate prevention, stale-proof rejection, and receipt completeness. Cycle time is useful only after the system stops counting an unverified patch as a completed task.

A practical implementation checklist

A production Discord-to-PR agent harness needs these controls:

1. Preserve immutable source identity in one durable semantic case record.
2. Separate feedback triage from actionable engineering state.
3. Make discovery, acknowledgment, dispatch, resume, and delivery independently idempotent.
4. Reuse one task per case, pin model routing, and bound escalation.
5. Isolate code in a scoped worktree and recheck the target revision on resume.
6. Lease shared clients and bind captures to task, case, revision, and expiry.
7. Require builds, tests, client QA, privacy review, and durable evidence.
8. Monitor material gaps without taking over intake, implementation, or approval.
9. Confirm a structured receipt at every linked source and keep merge authority human.

What this should feel like to the team

From the reporter’s side, the ideal experience is deliberately simple: report the problem once, see that it has an owner, and receive a clear result or blocker in the same conversation. The person should not have to chase task IDs, inspect worktrees, or reconstruct an agent transcript.

For the reviewer, the handoff should be equally calm: one current diff, the checks that ran, the client behavior that was exercised, the evidence that can be trusted, and the decision that still belongs to a human.

A useful engineering agent should make work easier to trust, not harder to inspect. That is what brings the system closer to a careful developer: not the ability to sound human, but the discipline to preserve context, show its work, and stop at the right boundary.