Don't Let Your Coding Agent Stop to Google Things

Your coding agent is in flow. It’s deep into implementing a rate-limited API client. Then it hits a question: what’s the current burst limit on the OpenAI completions endpoint? Has the streaming API behavior changed in recent SDK versions? Is there a known issue with the retry logic in httpx 0.27?

Here’s what happens next, and why both options are bad.

Option A: The agent stops to research. It burns 5-10 minutes on web searches, processes the results, and tries to reconstruct context when it comes back. Some of that context is gone. The momentum is broken. What should have been a 30-minute implementation session becomes 90 minutes of interrupted flow.

Option B: The agent guesses. It uses training data that could be months out of date. It produces code based on a rate limit that changed in last quarter’s API update, or a function signature that was deprecated in the last SDK release. The code ships. The bug appears in production.

Neither is acceptable. And both are unnecessary.

---

The problem is sequential execution

The reason your coding agent stops to research is that it has no way to do anything else. It’s a single-threaded workflow: question arises, agent handles question, agent continues. There’s no mechanism for saying “handle this in the background while I keep going.”

This is a coordination problem, not a capability problem. Your coding agent can write good code. A research agent with web search tools can find accurate, current information. The gap is that they can’t work in parallel without a shared task infrastructure.

AI agent task delegation is the pattern that fixes this. Instead of the coding agent doing the research itself, it delegates the research question as a task to a dedicated research agent, then continues building on the parts of the implementation that don’t depend on that answer. When the research task completes, the answer is waiting in a structured result blob. The coding agent reads it and fills in the gaps.

Parallel execution. No blocking. Accurate answers without stopping.

What you need

• A coding agent (Claude Code, Codex, or any MCP-compatible agent)
• A research agent with web search capabilities (Perplexity, Brave Search, or similar)
• Delega MCP server configured for both agents

The Delega MCP server is the coordination layer. It gives each agent its own identity and key on a shared task system. Assignment routes work to an agent; delegation records the accountable parent/child handoff; claims keep two workers from processing the same task.

Setting up the MCP multi-agent workflow

At launch, delega init walked users through public signup and agent creation. That flow now returns 410 hosted_service_retired; no new public keys are issued. The manual configuration below is retained as an as-built example for Ryan’s existing owner keys or a compatible private deployment:

Coding agent (~/.claude.json):

{
  "mcpServers": {
    "delega": {
      "command": "npx",
      "args": ["@delega-dev/mcp"],
      "env": {
        "DELEGA_AGENT_KEY": "dlg_coder_key_here"
      }
    }
  }
}

Research agent (same pattern, different key):

{
  "mcpServers": {
    "delega": {
      "command": "npx",
      "args": ["@delega-dev/mcp"],
      "env": {
        "DELEGA_AGENT_KEY": "dlg_researcher_key_here"
      }
    }
  }
}

Use list_agents to resolve the research agent’s ID. Labels can still categorize the work, but assigned_to_agent_id — not a label — determines the intended owner.

The delegation flow

1. Coding agent delegates a research task

Instead of pausing to search, the coding agent delegates from its current implementation task:

delegate_task(
  task_id="IMPLEMENTATION_TASK_ID",
  content="Verify the current model-provider rate-limit behavior needed by our retry logic. Cite primary sources and record the verification date.",
  assigned_to_agent_id="RESEARCH_AGENT_ID",
  labels=["research", "api-client"]
)

update_task_context(
  task_id="RESEARCH_TASK_ID",
  context={
    "blocking": "api-client-retry-logic",
    "required_evidence": "primary sources",
    "questions": ["request limits", "token limits", "burst-window behavior"]
  },
  source="agent_observed"
)

The task ID comes back immediately. The coding agent records it and continues implementing the parts of the client that don’t depend on the rate limit values: the request builder, the response parser, the error types.

2. Research agent picks it up

The research agent, configured to check its task queue on each run, calls list_tasks(completed=false) and finds the assigned research request:

{
  "tasks": [{
    "id": "RESEARCH_TASK_ID",
    "content": "Verify the current model-provider rate-limit behavior...",
    "status": "open",
    "labels": ["research", "api-client"],
    "assigned_to_agent_id": "RESEARCH_AGENT_ID"
  }]
}

It claims the task, runs the research using current primary sources, writes the result to persistent context, and completes the task:

claim_task(task_id="RESEARCH_TASK_ID", lease_seconds=1800)

update_task_context(
  task_id="RESEARCH_TASK_ID",
  context={
    "decision": "Read limits from response headers and configuration; do not hard-code account-tier numbers.",
    "sources": ["https://provider.example/docs/rate-limits"],
    "verified_on": "2026-07-23",
    "next_step": "Implement adaptive backoff and header-based telemetry."
  },
  source="agent_observed"
)

complete_task(task_id="RESEARCH_TASK_ID")

3. Coding agent reads the result

When the coding agent is ready to implement the rate limit logic, it calls get_task with the task ID it recorded earlier. If the task is complete, it gets the result. If it’s still pending, it can continue on other work and check again. No blocking. No waiting in place.

The final implementation uses the sourced decision, not training data or invented constants:

# Decision recovered from the research task context:
# read live response headers and use bounded exponential backoff.
limits = RateLimitState.from_headers(response.headers)
retry_after = limits.retry_after(attempt)

Why this works better than alternatives

Compared to the agent doing research itself: The coding agent stays focused. It doesn’t have to context-switch into “researcher mode.” Its token budget goes toward the implementation, not the search. Separation of concerns produces better output from both agents.

Compared to sequential agent runs: You don’t have to wait for research to finish before coding starts. The research happens in parallel. Total wall-clock time is shorter.

Compared to hard-coding the context: You don’t have to front-load your prompt with documentation that may be outdated. Research happens at task creation time with current data.

Compared to custom orchestration code: There’s no custom code to write or maintain. The task queue is the coordination protocol. Both agents use the same MCP interface they already know.

Scaling the pattern

One research agent is a start. The same pattern handles more complex delegations:

Multi-step research: The research agent creates a child task for a second, more specialized researcher. The coding agent only ever sees the final answer.

Competitive research: While coding agent A builds the feature, research agent B is comparing your implementation approach to how three competitors solved the same problem. The brief arrives before you need it.

Validation: After implementing, the coding agent creates a validation task asking the researcher to verify that the approach matches current best practices. The researcher comes back with a thumbs-up or a flag before the PR is opened.

Each of these patterns uses the same primitives: delegate a child task, assign it, save result context, complete it, and read the result. No direct agent-to-agent networking or custom queue is required.

← Back to blog