How I Built a 5-Agent AI Editing Engine for Proposals

Most teams think "AI editing" means pasting text into ChatGPT and asking it to "make this better." That's not a system. That's a prayer.

After a year building AI workflows for a Fortune 500 proposal team, here's what a production editing system actually looks like: the architecture, what breaks, and what I'd do differently.

Why One Agent Isn't Enough

The first version was a single prompt: "Edit this proposal section for grammar, style, and compliance." The output was mediocre. Everything was lightly touched. Nothing was great.

The problem: editing is not one skill. It's at least four different jobs that require different mindsets:

• Proofreading. Catching typos, spacing errors, punctuation. Mechanical. Low judgment.
• Copyediting. Grammar, consistency, style guide compliance. Rule-based with some judgment.
• Line editing. Sentence rhythm, weak verbs, nominalization. High craft.
• Substantive editing. Structure, argument flow, compliance with requirements. Strategic.

When you ask one model to do all four, you get average performance across all four. When you specialize, each agent becomes genuinely good at its specific job.

The Architecture

The system uses a hub-and-spoke model with five agents:

Document
    │
    ▼
ORCHESTRATOR
    │
    ├──► PROOFREADER ────────────► JSON edits
    ├──► COPYEDITOR ─────────────► JSON edits
    ├──► LINE EDITOR ────────────► JSON edits
    └──► SUBSTANTIVE EDITOR ─────► JSON comments
              │
              ▼
    ORCHESTRATOR merges + resolves conflicts
              │
              ▼
    Word doc (.docx) with tracked changes

Each specialist agent returns structured JSON, not prose. The orchestrator handles all document manipulation. This separation matters: only one process touches the file, which eliminates conflicts.

The Agents in Detail

Agent 1: Proofreader

Scope is tightly constrained to mechanical errors only: spelling, spacing, punctuation, capitalization. It's explicitly told not to change word choice, restructure sentences, or add content. Runs fast. High confidence on its output.

Agent 2: Copyeditor

Works against a loaded style guide. In our case: Chicago Manual of Style + a custom brand voice document. It catches consistency issues across the whole document (using the same term for the same thing throughout), wordiness, passive voice overuse, and grammar issues the proofreader missed because they're judgment calls, not errors.

Agent 3: Line Editor

The highest-craft agent. Focused on sentence-level quality: nominalization ("the implementation of" → "implementing"), weak verbs ("There is a need to" → "We need to"), sentence rhythm, and paragraph-level restructuring when flow breaks down. This agent makes the writing actually sound good.

Agent 4: Substantive Editor

This one doesn't make direct edits. It leaves comments only. It checks whether each section actually answers the question being asked (critical for RFP compliance), flags missing content, identifies structural problems, and notes where the argument breaks down. It's the strategic layer.

Agent 5: Orchestrator

Coordinates everything. Takes the JSON output from each specialist, resolves conflicts (what happens when the copyeditor and line editor both want to change the same sentence?), applies edits to the actual .docx file as tracked changes, and converts substantive comments to Word margin notes.

What Actually Breaks in Production

Long documents kill context windows. A 50-page proposal section-by-section works fine. A 50-page proposal in one shot does not. The solution: chunk by section heading, process in parallel where possible, stitch back together.

Style guide drift. If you give the copyeditor a 40-page style guide, it picks favorites and ignores the rest. Solution: distill the style guide to the 20 rules that actually matter in proposal writing. The agent performs better with 20 crisp rules than 200 exhaustive ones.

The substantive editor hallucinates requirements. When it doesn't have the original RFP to check against, it invents compliance criteria. Fix: always pass in the evaluation criteria from the RFP alongside the section being reviewed.

Tracked changes formatting. python-docx handles this differently than Word expects. You will spend more time on .docx manipulation than on the AI logic. Accept this.

Results After 6 Months in Production

The team still reviews everything. This isn't autonomous editing. It's an AI editor that works alongside humans, not instead of them. What changed:

• First editorial pass time cut from ~4 hours to ~30 minutes for a 50-page document.
• Consistency errors (using different terms for the same concept) dropped to near zero.
• Junior writers produce work closer to senior writer quality on first submission.
• The substantive editor catches compliance gaps before reviewers see them.

The system doesn't write better than a great human editor. But it writes considerably better than a tired one at 11pm before a submission deadline. Which is usually when proposals get edited.

What I'd Do Differently

I'd build the style guide distillation process from day one instead of discovering it at month three. The most important thing you can give a copyediting agent is a short, specific, prioritized list of the rules that matter most for your document type.

I'd also add a confidence scoring layer. Right now the orchestrator applies all edits with equal weight. A future version would score each edit by the agent's stated confidence and flag low-confidence edits for human review rather than auto-applying them.