7UNIT / CASE STUDY 005

AI SYSTEMS · ENGINEERING OPS · INTERNAL

IN PILOT

Claude API · ClickUp API · GitHub API · FastAPI

The maintenance loop —delegated to a team of agents.

Bug triage. Code analysis. Fix proposal. Automated code review. PR raised. The entire bug resolution workflow handled by four coordinated agents — with a developer approving every fix before a single line of code changes.

THE SITUATION

The best engineers you hire will do the hardest technical work gladly. What they will quietly resent — and eventually stop doing well — is the maintenance loop.

A bug arrives in ClickUp. By the time it has been reproduced, the relevant code located across a codebase that may span hundreds of files, the root cause identified, a fix designed and implemented without breaking adjacent logic, the code reviewed for quality and regression risk, a PR written with adequate context, and the branch merged — three hours of a senior engineer's attention are gone. Spent on work that required skill but produced no new capability.

Multiply this by every bug in a sprint. Add the cognitive cost of switching between building new features and maintaining existing ones. You begin to understand why maintenance culture in engineering teams is structurally difficult to sustain — not because engineers lack the skill, but because the work competes with everything they find meaningful about engineering.

At 7Unit, we built a system to handle this. Not to remove engineers from the loop — to remove the overhead before the loop begins. We call it the Engineering Agent Team.

FOUR AGENTS. ONE WORKFLOW.

Each agent has a defined role and a defined boundary. They hand off to each other through a structured context object that carries the full state of the bug resolution from first intake to final PR. No agent acts outside its boundary. No agent proceeds without the previous agent completing its job.

INTAKE

Bug Intake Agent

Monitors the ClickUp workspace continuously for new bug reports entering the engineering queue. When a bug is created or reaches the defined trigger status, the Intake Agent reads the ticket, classifies the bug by severity and type, and initiates the analysis workflow by passing a structured context object to the next agent.

No engineer manually triages the queue. Every ticket is read, classified, and routed — automatically, as soon as it arrives.

What it handles:

Continuous ClickUp monitoring for new bug tickets
Severity classification: critical, high, medium, low
Type categorisation: logic error, UI defect, performance regression, configuration, integration
Context packaging: bug description, reproduction steps, affected area — structured for the next agent
Workflow initiation: passes to Code Analysis + Fix Proposal Agent

ANALYSIS + PROPOSAL

Code Analysis and Fix Proposal Agent

This is the most technically demanding agent in the system. It receives the bug context from the Intake Agent, connects to the GitHub repository, and does the work a senior engineer would normally spend an hour on: locating the relevant code, tracing the execution path, identifying the root cause, and designing a fix.

Critically — the same agent that analyses the bug is the one that proposes the fix. This is intentional. The context built during analysis does not need to be handed off and re-established. The agent reasons from understanding to proposal in a single pass, which produces more coherent and consistent fix recommendations than splitting these responsibilities across separate agents.

The proposal is posted back to the ClickUp ticket as a structured comment. The developer is notified. Their job is to read an analysis and decide whether they agree — not to start the investigation from scratch.

What it produces:

File and function location of the probable root cause
Execution path trace showing how the bug manifests
Adjacent code risk assessment
Specific code change recommendation with rationale
Edge cases the fix accounts for
Explicit questions for the developer where confidence is partial
Clear approval prompt posted to ClickUp

Developer touchpoint:

This is the first human gate. The developer reads the analysis, reviews the proposed fix, and either approves or rejects with notes. Approval triggers the Implementation step. Rejection returns to this agent with the developer's feedback as additional context for re-analysis.

REVIEW

Automated Code Review Agent

Most systems like this go from fix implementation directly to PR. We inserted a code review agent between them — and this is the architectural decision that most distinguishes this system from simpler implementations.

After the approved fix has been implemented, the Code Review Agent examines the code changes before the PR is raised. It checks the implementation against three criteria: correctness (does the change actually address the root cause as proposed), pattern consistency (does the new code follow the established conventions of the existing codebase), and regression risk (could this change affect adjacent functionality).

The result: the PR that reaches the developer for final review has already been checked by an agent. The developer is not reviewing raw code for basic quality issues — they are reviewing code that has passed an automated review gate. Their attention goes to the judgement call, not the checklist.

What it checks:

Implementation matches the approved proposal exactly
Code follows project naming and structural conventions
Error handling is consistent with existing patterns
No obvious regression risk in adjacent functions
Logging and observability patterns maintained
Passes or flags — no partial states

If the review flags an issue, the fix goes back for revision before the PR is raised. A developer never sees a PR that failed the code review gate.

Pull Request Agent

The final agent in the chain. Activates only after the Code Review Agent has cleared the implementation.

Creates a named branch following the project's established conventions, applies the reviewed code changes, and raises a pull request against the main branch. The PR description is structured — not auto-generated boilerplate. It contains the ClickUp ticket reference, a summary of what changed and why, what was tested by the code review agent, and specific guidance for the human reviewer.

The developer reviews the PR, verifies the diff is consistent with what they approved, and merges. The PR agent does not merge. Final merge is always a human action.

What it produces:

Named branch following project conventions
Clean commit with the approved code changes
PR with structured description:
— ClickUp ticket reference and bug summary
— What changed and the rationale
— Code review agent findings
— What the human reviewer should verify
— Any open questions
Reviewer notification

WHY SUPERVISION IS NON-NEGOTIABLE

This system was designed around one constraint that is architecturally enforced, not just conventionally observed: a developer approves every fix before any code change is made, and a developer merges every PR. These are hard gates in the orchestration logic — not confirmation dialogs that can be skipped.

An agent system that can modify a production codebase without human approval is an agent system that can introduce bugs without accountability. The value of this system is not removing engineers from the process. It is removing the overhead before engineers need to engage — so when they engage, they are doing the work that actually requires their judgement.

The developer's first touchpoint is reviewing a structured fix proposal, not a raw ticket. Their second touchpoint is reviewing a PR that has already passed an automated code review. In both cases they are making a decision with full context already assembled. The cognitive work of investigation, analysis, and quality checking has been handled. What remains is the judgement call.

That is what senior engineers are for.

END TO END

STEP 01

Bug reported in ClickUp

A bug enters the engineering queue — from a tester, a client, or a developer. No manual triage needed.

HUMAN

STEP 02

Intake Agent classifies and routes

The agent reads the ticket, classifies severity and type, packages the context, and initiates the analysis workflow. The queue moves without anyone touching it.

AGENT

STEP 03

Code Analysis + Fix Proposal Agent investigates

The agent connects to GitHub, locates the relevant code, traces the root cause, and proposes a specific fix. The full analysis is posted to the ClickUp ticket as a structured comment.

AGENT

STEP 04

Developer reviews the analysis and decides

The developer reads what the agent found and what it proposes. They approve, reject with notes, or request deeper analysis on a specific area. This is the critical human decision point.

HUMAN · DECISION POINT

STEP 05

Fix is implemented

On approval, the code change is applied based on the approved proposal. The implementation follows the design the developer agreed to.

AGENT

STEP 06

Code Review Agent examines the implementation

Before any PR is raised, the Code Review Agent checks the implementation for correctness, pattern consistency, and regression risk. If it flags an issue, the fix is revised before the developer sees it.

AGENT

STEP 07

PR Agent raises the pull request

A named branch is created, the reviewed code is committed, and a structured PR is raised against main — with full context, ticket reference, and reviewer guidance.

AGENT

STEP 08

Developer reviews and merges

The developer reviews the PR diff, confirms it matches the approved proposal, and merges. The agent does not merge. This action is always human.

HUMAN · FINAL ACTION

THE OPERATIONAL IMPACT

For the senior engineer

The maintenance loop no longer competes with meaningful work. Bugs arrive as structured proposals, not as raw tickets requiring investigation from scratch. Senior engineers make judgement calls with context already assembled — which is what they are actually for.

For the junior engineer

Every agent analysis is a learning artefact. A junior developer reviewing a fix proposal from the Code Analysis Agent is reading a structured explanation of how the bug manifested and why the fix addresses it. This is better than most code review feedback — and it happens on every single bug resolved through the system.

For the codebase

The Code Review Agent enforces the patterns it was trained on. Fix implementations follow existing conventions — naming, structure, error handling, logging — because the agent knows the codebase and writes to match it. Code consistency improves not because you mandate it but because the agent enforces it.

For the team lead

Bug resolution velocity increases. The bottleneck — the cognitive work of initial investigation — is handled before a developer touches the ticket. More bugs resolved per sprint without adding headcount or burning out the engineers you have.

UNDER THE HOOD

For engineering leaders evaluating this — the stack, the integration points, and the design decisions.

Agent orchestration

Built on Claude API (Anthropic). The four agents run as a coordinated workflow, not as independent chatbots. State is carried through a structured context object from intake through to PR — each agent receives the full history of what the previous agents did and decided.

ClickUp integration

Webhook-driven. New tickets in the defined trigger status activate the Intake Agent. The Analysis + Proposal Agent posts structured comments back to the original ticket. Developer approval is captured through a ClickUp response — no additional tool required for the developer.

GitHub integration

GitHub API for repository read access, branch creation, commit, and PR creation. The Analysis Agent fetches relevant files based on bug context. The Code Review Agent reads the implementation diff. The PR Agent creates the branch and PR. All actions are attributed to a service account with a complete audit trail.

The approval gate — enforced architecturally

The Implementation step cannot run without a confirmed approval state in the workflow context. The Code Review Agent cannot run without a completed implementation. The PR Agent cannot run without a clean code review result. These are hard gates in the orchestration logic — not convention, not confirmation dialogs. Architecturally enforced at every transition.

Codebase pattern context

The Analysis and Code Review agents are initialised with context from the project's existing codebase — conventions, naming, structural patterns, error handling approaches. The system writes and reviews code that matches the codebase because it was given the codebase as context from the start.

Configurability

Configured per team and per repository. ClickUp workspace, GitHub organisation, branch naming conventions, PR templates, trigger statuses, notification routing, and escalation paths are all set during implementation. The architecture is repeatable. The configuration is specific to your team.

WHERE THIS IS NOW

The Engineering Agent Team is currently running in a closed pilot within 7Unit's own engineering workflow. The architecture is stable, the integrations are tested, and the four-agent workflow is operating on real bugs against a real production codebase.

We are making this available to engineering teams now — ahead of general availability — because we believe the teams that adopt this model earliest will have a structural operational advantage. The maintenance loop is a universal problem in software engineering teams. The agent team is a repeatable, configurable solution.

We are also aware that other teams are working on similar systems. We are not waiting for perfect. The system works, the pilot is running, and the architecture is sound. If this is a problem your team has, it is worth a conversation now.

Available for early implementation

We are taking a limited number of early implementation engagements outside the pilot. If your engineering team spends meaningful sprint capacity on bug triage and maintenance overhead — and you want to understand what delegating that to a supervised agent team would look like — the first 30 minutes is free.

Book a discovery call →

WHAT THIS IS NOT

This system handles the maintenance loop. It does not write features. It does not make architectural decisions. It does not merge code without human review. It does not replace the engineers on your team.

What it replaces is the overhead before your engineers engage — the investigation, the analysis, the first-pass code review. That overhead is real, it is expensive, and it compounds across every bug in every sprint.

That is the specific problem this solves.

7UNIT / START HERE

Your engineers should be building, not triaging.

If the maintenance loop is costing you senior engineer attention every sprint, let's talk about what delegating it to agents would look like for your team.

Book a discovery call →← Back to all work

No pitch. We listen to your workflow, look at your stack, and tell you honestly whether this is a fit — even if the answer is not yet.

← Back to all work