Attention-Constrained Multi-Agent Optimization: TDD and Context Management

In software development, the central challenge of multi-agent collaboration is not the number of agents, but the precision of attention allocation. A planner may overlook constraints, a coding agent may read outdated documentation, a testing agent may verify only surface behavior, and a reviewer may be overwhelmed by excessive context.

By treating attention as a constrained resource-scheduling problem, task relevance, risk level, verification value, and invocation cost can be incorporated into a unified collaboration loop. This enables agents to make more stable decisions within limited context windows and budgets. Using software development process data as an example, this article discusses a practical optimization framework.

1. Overall Approach: Treat Attention as a Constrained Scheduling Resource

Here, “attention” does not refer to an opaque internal model weight. It refers to an engineering-level attention budget. Given a large volume of candidate information—including requirements, design documents, change diffs, test logs, defect records, and review comments—the system must determine which content should enter the current agent’s context, which should be summarized, which should be loaded later, and which should be removed.

A simplified optimization objective is to minimize invocation cost, defect escape rate, and context redundancy while maximizing verification coverage and decision traceability, subject to hard constraints such as permissions, security requirements, and passing tests.

This produces four dimensions of constraint:

1. Task attention: Focus each step only on the requirements, interfaces, and acceptance criteria directly related to the current objective.
2. Risk attention: Give high-risk changes stronger models, additional review, and stricter safeguards.
3. Verification attention: Prioritize failed-test summaries, boundary conditions, and historical defect patterns.
4. Cost attention: Assign low-risk classification, summarization, and formatting tasks to lightweight models, escalating to more capable models for complex reasoning.

The overall workflow can be summarized as follows: the planning phase decomposes the task and allocates an attention budget; an annotation-decision loop records intent and acceptance criteria near the code; a project-level instruction system discloses rules progressively; context management continuously compresses and evicts information; the TDD loop provides strong feedback; deterministic safety hooks provide a fallback boundary; and cost-aware routing and troubleshooting complete the loop.

2. Planning: Allocate Attention Before Assigning Tasks

The planning phase should produce more than a list of steps. It should also define the context scope, risk level, acceptance criteria, and budget for each step.

For example, a requirement might be divided into:

• Identify the affected components
• Add a failing test
• Implement the smallest necessary change
• Run verification
• Review the diff

Each step should specify the modules that need to be read, paths that must not be modified, tests that must pass, and the permitted model tier.

The planner should avoid loading the entire repository at once. Instead, it should generate an “attention plan” that identifies which files require full reading, which need only a summary, and which should be retrieved on demand.

For high-risk operations—such as authentication, billing, data deletion, and concurrency control—the system should increase review attention and enforce deterministic safeguards. The plan should also include a fallback strategy. If tests fail repeatedly, the system should narrow the context and return to a summary of the failure rather than continuing to accumulate historical conversation.

3. The Annotation-Decision Loop: Place Precise Decisions Near the Code

The goal of an annotation-decision loop is to give agents short, structured, and highly relevant decision context at critical locations. Code comments should not become lengthy explanations. Instead, they should capture intent, constraints, acceptance criteria, and risk signals.

For example:

// intent: Allow updates only for authorized resources
// constraint: Do not change the public interface signature
// acceptance: Unauthorized requests are rejected; authorized requests remain idempotent
// risk: High; add boundary tests and require review

After reading these structured annotations, the agent generates a patch and writes the decision record back into the change description or review record.

This approach offers several benefits:

• The annotations are close to the code, reducing attention distance.
• Constraints can be reused by tests and hooks.
• Future maintainers can understand why the implementation was chosen.

Annotation pollution must also be avoided. Temporary reasoning should not be written into production comments. Outdated annotations should be removed with the corresponding change. When annotations and tests disagree, tests and enforced rules should take precedence, and the conflict should trigger a review.

4. Project-Level Instructions: Progressive Disclosure and Rule Hierarchies

A project-level instruction system can store security requirements, directory conventions, coding standards, testing requirements, and review checklists. The key is not to place every rule into the context at once, but to use progressive disclosure:

• Global security rules remain loaded at all times.
• Project conventions are loaded as a summary when the task begins.
• Module-specific rules are loaded when the agent enters the relevant directory.
• Temporary task instructions apply only to the current step.

Rules should be layered with explicit priorities:

1. Security and compliance rules
2. Project-level conventions
3. Module-specific standards
4. Temporary task instructions

Temporary instructions must not override higher-priority rules.

Instruction files should be versioned, reviewable, and diffable to avoid hidden rules. When rules conflict, the system should output a conflict summary and request a deterministic rule-based resolution instead of allowing the model to guess.

Progressive disclosure can substantially reduce context redundancy and lower the chance that an agent overlooks an important constraint because too many rules are present.

5. Context Management: Eviction, Compression, and Retrieval First

The core principle of context management is to retain the minimum sufficient information required for a decision. The following strategies are useful:

• Segment scoring: Score content by task relevance, freshness, risk, and verification value. Summarize segments that exceed the budget before evicting them.
• Layered retention: Retain requirements, acceptance criteria, failed-test summaries, and decision records for longer. Keep tool output and intermediate reasoning only temporarily.
• Document eviction: Remove completed steps, outdated design documents, duplicate logs, and unrelated files from the active context.
• Retrieval first: Retrieve interface documentation, historical defects, and test cases for the current step instead of injecting entire documents.
• Deduplication and compression: Merge repeated error messages while retaining failed assertions, key stack frames, and the impact of recent changes.

Context eviction is not simple deletion. Reusable conclusions should be preserved as summaries with traceable references.

For test failures, retain four elements:

1. The failed test case
2. The expected behavior
3. The actual behavior
4. The most recent related change

This prevents the next agent iteration from repeating the same investigation.

6. The TDD Loop: Use Verification Attention to Drive Collaboration

The TDD loop provides strong feedback for multi-agent collaboration: add a failing test, implement the smallest change, then refactor and run regression tests.

The testing agent converts acceptance criteria into executable assertions. The coding agent modifies only the areas allowed by the tests and constraints. The reviewer checks whether the tests genuinely cover the requirement and prevents the system from “fixing the test” instead of fixing the implementation.

A simplified collaboration loop can be represented as follows:

collaborate(task, budget):
  plan = planner.decompose(task, attention_budget)
  context = context_manager.load(plan.scope)
  for step in plan.steps:
    note = annotate(step, constraints, acceptance)
    rules = instructions.disclose(step.scope)
    patch = coder.generate(context, note, rules)
    if not hooks.validate(patch, context):
      context.add(hook_failure_summary)
      continue
    result = tester.run(acceptance)
    if result.fail:
      context.add(result.failure_summary)
      continue
    reviewer.audit(patch, result, risk=step.risk)
    context_manager.compact_and_evict()

During TDD, attention should remain focused on failed assertions and acceptance criteria rather than historical conversation.

When failures continue, the system should trigger a fallback strategy:

• Narrow the modification scope
• Request review by a stronger model
• Pause automatic changes and generate a failure analysis instead

7. Deterministic Safety Hooks: Hard Boundaries Beyond Model Judgment

Safety hooks enforce non-negotiable deterministic rules, such as path allowlists, restrictions on writing sensitive files, dependency-change reviews, patch-size limits, required test execution, tool-call timeouts, and audit logging.

Hooks should operate both before and after tool calls:

• Before a call, validate permissions and parameters.
• After a call, validate the result and test status.

A model may make recommendations, but it must not be able to bypass the hooks.

Hook rules should be few and strict enough to avoid false positives that stall collaboration. Each rule should include a clear error code, remediation guidance, and an exemption process. Exemptions must be reviewed and recorded with their rationale.

Separating deterministic rules from model judgment reduces hallucination risk and makes troubleshooting more evidence-based.

8. Cost Optimization and Model Selection: Route by Attention Value

Cost optimization is not simply a matter of switching to smaller models. It requires routing work according to attention value.

Summarization, classification, formatting, and log aggregation can be assigned to lightweight models. Complex planning, cross-module reasoning, and high-risk review should use more capable models.

Other useful techniques include:

• Caching project instruction summaries
• Reusing retrieval results
• Batching low-risk tasks
• Setting early-stop conditions
• Controlling budgets by workflow step

Model selection should account for task risk, context length, verification difficulty, and the cost of failure. For high-risk steps, an additional review is preferable to introducing defect escapes through overly aggressive low-cost routing.

Cost metrics should be evaluated together with quality metrics, including:

• Cost per test-passing change
• Number of invocations per defect fix
• Context compression ratio
• Human rollback rate

9. Common Problems and Troubleshooting

Context drift: The agent repeatedly modifies unrelated files. Check whether the attention plan is too broad, narrow the read scope, and remove outdated summaries.

Instruction conflicts: The same task receives contradictory rules. Output a conflict list and resolve it according to the priority order of security, project, module, and task rules.

Brittle or deceptive tests: Tests pass, but the behavior is incorrect. Review test changes, add boundary assertions, and strengthen deterministic hooks.

False-positive hooks: A valid change is blocked. Check the rule granularity and add clear error codes and an exemption process.

Multi-agent waiting or duplication: Agents wait for one another or repeat the same work. Define an explicit state machine and timeout policy, and designate a single writer for failure summaries.

Uncontrolled costs: Long contexts and repeated calls drive up usage. Enable segment scoring, caching, early stopping, and risk-based routing.

For software development process data, teams can collect requirement items, change descriptions, test results, defect labels, and review comments. After de-identification, this data can be indexed for retrieval, while historical failure patterns can serve as attention priors. The collaboration strategy should then be evaluated continuously using metrics such as verification pass rate, rollback rate, and cost.

By combining attention constraints, progressive disclosure, context eviction, TDD, and deterministic hooks, multi-agent collaboration can move beyond demo-level capabilities toward an engineering practice that is auditable, controllable, and continuously optimizable.