Multi-agent job search

The common mistake is one agent per pipeline stage: a search agent, a scoring agent, a writing agent, a submission agent. That is a workflow, and a workflow does not need agents — it needs functions, which are cheaper and deterministic.

Split where the work genuinely differs in kind. Browsing an unfamiliar site is a different competence from judging whether a CV meets a requirement, and different again from writing a cover letter. Those boundaries justify separate agents with separate tools and prompts.

A useful test: if the component always runs in the same place in the sequence, always receives the same shape of input and always produces the same shape of output, it is a function with a model call inside it. Agency means choosing what to do next, and most pipeline stages do not.

Agents that negotiate with each other produce impressive transcripts and unpredictable outcomes. Someone has to decide, and that someone should be an orchestrator with plain logic rather than a committee of models.

Keep the orchestrator dumb on purpose: it routes, it enforces limits, it decides when to stop. Every piece of judgement is delegated to a specialist, and every piece of control stays in code where it can be audited.

The payoff is that limits actually hold. A budget enforced by an orchestrator that cannot be reasoned with is a real constraint; one distributed across agents that each believe their next call is justified is a suggestion.

• Orchestrator: routing, budgets, stopping conditions — deterministic
• Specialists: one competence each, narrow tools
• No agent-to-agent messaging that bypasses the orchestrator
• All state changes recorded centrally, not inside an agent

When one agent hands another a free-text summary, detail is lost and errors compound — the second agent acts on a paraphrase of a paraphrase, and by the fourth handoff nobody can reconstruct what was decided.

Define a schema for each handoff and validate it. A scoring agent returns scored identifiers with reasons, not a paragraph about what it thought. This also makes each agent independently testable, which a conversational handoff never is.

Validation should reject rather than repair. An agent returning a malformed result is a signal worth surfacing, and silently coercing it into the expected shape hides a defect that will reappear as a wrong answer somewhere further down.

Each agent has its own context, its own prompt and its own reasoning tokens. Five agents is not five times the cost of one — it is more, once handoffs, retries and the orchestrator’s own calls are counted.

The multi-agent version has to be enough better to justify that. Often a single well-prompted agent with good tools matches it, and the only honest way to know is to build the simple version first and measure what the split buys.

Latency compounds in the same way and is felt sooner. Sequential agents each waiting on a model call turn a four-second operation into thirty, and a user watching a spinner does not care how elegant the decomposition is.

A single agent that fails has failed. In a multi-agent system, one specialist failing leaves the others holding partial work, and the orchestrator has to decide whether to retry it, proceed without it, or abandon the run — and those need to be decided in advance rather than improvised.

Partial success is the common case and the one most designs ignore. Scoring succeeded, generation failed: the scored shortlist is valuable and should be kept, and repeating the expensive scoring on retry is pure waste.

Checkpoint after each specialist returns, so a retry resumes rather than restarts. This is the same durability argument as for any long-running process, and it applies more sharply here because each step is expensive.

• A defined policy per specialist: retry, skip, or abandon
• Checkpoints after each handoff so retries resume
• A cap on total retries per run, not just per agent
• Partial results kept and surfaced rather than discarded

When a single agent misbehaves you read its trace. When five agents interact, the question is which one went wrong, which handoff carried the error, and whether the orchestrator should have caught it.

Budget for this before you build. Log every handoff with its full input and output, tag every message with a run identifier, and make each agent runnable in isolation against a recorded input. Without that, a multi-agent system becomes unmaintainable well before it becomes impressive.

Recorded handoffs double as a test suite, which is the one compensation this architecture offers. Real inputs captured from production, replayed against a single specialist, catch a regression in that specialist without running the whole system — and that is worth more than any amount of synthetic test data.