Do you need an AI harness if you already use an issue tracker?

Do you need an AI harness if you already use an issue tracker? Often not at first. A good tracker already holds the task list, ownership, discussion and history, and plenty of teams run AI coding agents straight from issues with nothing else. The question is what agent work adds that a tracker was not designed for: assembling the right context for each run, stating what a run may touch, tying checks to the specific attempt, and recording what the agent actually did, with its usage. People carry those things in their heads and in pull request reviews; agents need them written down every time. If your agent work is a few issues a week, each handled in one session and reviewed through a pull request, the tracker plus your normal review is enough. If you find yourself pasting the same background into every session, losing track of which agent touched what, or unable to say which checks ran for a closed issue, the gaps are the ones a harness fills. This page lays out both sides.

What issue trackers already do well

Issue trackers solve coordination between people, and they solve it well. They give a team one shared queue with priorities, owners and due dates. They hold discussion next to the work, so the reason behind a decision is often in the thread. They link to commits and pull requests, so history connects to code. They have permissions, notifications, search, boards and reports that a whole organization already knows how to use.

For agent work, several of these carry over directly. An issue is a reasonable place for a task description an agent can read. Labels and states can mark what an agent may pick up. Pull request review is a strong acceptance gate, because a person reads the diff and CI runs the tests before anything merges.

Do not underestimate how far this goes. A team that writes clear issues, links each agent's pull request to its issue, and requires a passing CI run and a human review before merge has covered planning, checks and much of the record. Adding a second system in parallel has a real cost: two places to update, and two versions of the truth when they drift apart.

What agent work adds

The gaps appear in the parts of the work people do implicitly.

Context assembly. A developer picking up an issue knows the codebase, remembers last month's decision and follows links in the thread. An agent sees what it is given. Someone has to decide, for each run, which decisions, dependencies and files it gets, within a size budget.

Scope and authority. An issue says what should happen, not what a run may touch. Agents edit whatever seems relevant. A scope that names files or directories, and a separate decision that this run may go ahead, are agent-specific needs. See scope control for AI agents.

Checks tied to an attempt. CI runs on a pull request, which is good. But an agent may make three attempts in one session, run its own partial tests and report success. Knowing which checks ran on which state of the code is a per-run record.

Run records. Who ran, with which prompt, which files changed, what it reported, what usage it recorded, how it ended. Agent run history covers what a useful record holds.

Concurrency. Two agents can pick up related issues and edit the same files in parallel; the tracker will not stop them.

Stretching a tracker to cover agent work

Before adopting another tool, see how far conventions get you.

Add an agent section to your issue template: scope (files or directories the change may touch), the acceptance check (a named test or command that fails now and must pass), linked decisions, and dependencies on other issues. That turns a request into a task an agent can finish; writing tasks agents can finish has examples.

Use a label or state that means approved for agent work, distinct from merely written. Only items with that label get picked up.

Keep a short decisions file in the repository and link entries from issues, so context lives in files the agent can read.

Require each agent pull request to include the agent's summary, the command it ran to check, and the issue link. CI reruns the checks independently.

Use one branch per issue and avoid assigning overlapping files to parallel agents; preventing agents from editing the same files covers the patterns.

This setup is quick to adopt and works well for one to three concurrent agents. Where it strains is context assembly, which stays manual, and run records, which end up scattered across terminal scrollback and pull request descriptions.

When a tracker is enough, and when it is not

A tracker plus conventions is usually enough when agent work runs through pull requests with CI, when tasks finish in one session, when one person is directing agents and remembers the context, and when nobody asks later which checks ran for a given change.

It strains when tasks span several sessions and each new session needs the same background rebuilt; when agents run unattended and there is no pull request moment where a person looks; when several agents work at once on related parts; when you need dependencies enforced, not just noted, so that task B cannot start until task A is accepted; or when you must show, for an audit or for your own confidence, what each run was allowed to do and what verified it.

A harness does not have to replace the tracker. Many setups keep the tracker as the team's planning surface and use a harness for the execution layer: context, scope, runs and evidence. The practical question is where the source of truth for a task's status lives, and that should be decided once, not left to drift between two systems. For the broader contrast between work records and conversations, see project cards vs chat threads.

QUESTIONS

Can I run AI coding agents directly from issues?

Yes. Write the issue as a task: scope, an acceptance check that fails now, linked decisions and dependencies. Give the agent the issue text and the relevant files, have it work on a branch and open a pull request, and let CI and a human review decide. This works well while one person directs a few agents at a time.

What should an issue template include for AI agent tasks?

The outcome in one sentence, the files or directories the change may touch, a named test or command that must pass, links to relevant decisions, and any issues that must land first. Add a field for the agent's summary and the checks it ran, so the closing record says what verified the change.

Should agent tasks live in the same tracker as human tasks?

Usually yes for planning, because priorities and ownership should be visible in one place. Mark which items are approved for agent work. Execution details such as context bundles, run logs and per-attempt check results can live elsewhere, as long as each task's status has exactly one source of truth that everyone agrees on.

RELATED GUIDES

• How to create a project card in BRAIN FLUID Desk
• How to find and organize work across projects

RELATED HARNESS PAGES

• project cards vs chat threads Project cards vs chat threads: when a conversation with an AI agent is enough, and when a structured card record is the better home for the work.
• How to write a task an AI coding agent can finish How to write a task an AI coding agent can finish: one outcome, a scope, dependencies, completion criteria and the check that proves them.
• agent run history and reports Agent run history and reports: what to record about AI agent runs, how to read usage coverage honestly and where unknown differs from zero.
• Keeping AI coding agents within scope Keeping AI coding agents within scope: declare paths, approve them separately with an expiry, check writes during the run and compare the diff after.
• When you don't need an AI project harness When you don't need an AI project harness: short scripts, one-off tasks and short-lived repos where plain agent sessions plus a notes file are enough.