Building Three AI Agents That Actually Talk to Each Other - A Systems Breakdown

I want to walk through a system I built recently, because the thinking behind it matters more than the finished product. This isn't a highlight reel, it's how I actually approach building something: map the real workflow first, build the smallest system that solves it, then simplify once I can see it in action.

Starting With the Actual Workflow, Not the Tool

Before touching any AI agent or automation platform, I map the real process first. In this case: a job finishes on-site, rough notes come back (sometimes just a few lines, sometimes a voice memo transcribed badly), and someone has to turn that into a clean, accurate, compliant quote.

The real opportunity wasn't "add AI." It was: information was getting lost or garbled between the field and the office, with no consistent way to catch what was missing before it became a problem downstream.

That reframe shaped everything I built next.

Building the System - Three Connected Agents, Not One Big One

I could have built one large agent that tried to do everything. I didn't, deliberately. Instead, I split the workflow into three distinct stages, each with its own agent and its own job:

Agent 1 - Intake.

Takes rough field notes (and photos) and turns them into a clean, structured summary. It flags what's missing — critical, important, or nice-to-have — so the next step knows exactly what to chase before quoting even starts. It also reads uploaded site photos directly, flagging visual concerns without anyone needing to write a paragraph describing what a photo shows.

Agent 2 - Quote Builder.

Only picks up work once Agent 1's intake is actually resolved. It builds a professional, branded quote — itemized pricing, compliance notes explained in plain English, clear exclusions so scope doesn't quietly creep later. If something critical is still unresolved, it refuses to generate a quote at all. That refusal is intentional; a fast, wrong quote is worse than a slightly slower, correct one.

Agent 3 - Review & Approval.

Pulls the draft quote, runs it through a structured checklist, and won't produce a final version until every flagged issue is explicitly resolved by a human. The output is a clean, ready-to-send document with every internal note stripped out — and a visible authorization trail (name, position, date) so there's real accountability behind every quote that goes out the door.

How I Made the Apps Actually Talk to Each Other

This is the part people often skip past, but it's where most systems quietly fall apart: the handoff between steps.

I used Google Drive as the single shared source of truth across all three agents. Every job automatically gets its own folder the moment it enters the system — no one has to remember to create it, name it consistently, or file anything manually. Photos, draft quotes, review reports, and final approved documents all land in the same place, in a predictable structure, so anyone involved can find a job's full history without asking someone else for a file.

On top of that, a simple Google Sheets tracker gives a single-glance view of every job's status across all three agents - what's pending, what's in progress, what's done. No need to open three different tools to answer "where are we on this."

Prototyped on Google Drive - But Not Locked to It

I built and tested this system using Google Drive as the shared source of truth, mainly because it's fast to prototype in and easy for anyone to open and inspect without extra tooling. But the architecture itself doesn't depend on Google Drive specifically - it depends on having one reliable place every agent and every person can check.

That means the same three-agent pattern can drop into whatever a business already runs on, without asking anyone to switch tools they're already comfortable with. A few realistic swaps:

• Already on Microsoft 365? SharePoint or OneDrive plays the same role Drive does here - same folder logic, same automatic filing.
• Running a CRM or field service platform that already stores files and job records? The agents can write directly into that platform's existing structure instead of a separate folder system.
• Prefer a database-style source of truth? Airtable or a simple internal database can replace the Sheets tracker, giving the same at-a-glance status view with more structure.

The point isn't Google Drive specifically. The point is designing the handoff logic so it's portable - built once, then pointed at whatever's already in use, rather than asking a business to adopt a new platform just to get the automation.

Designing for API and Webhook Integration, Not Just File Handoffs

Google Drive and Sheets work well as a visible, human-friendly source of truth - but I also designed this system with an eye toward direct system-to-system integration, for when a business is ready for it.

As part of the build, I structured the quote data as clean, well-formed JSON - the format most platforms expect when receiving data through an API — so that once a target system's API is confirmed and available, that data can push directly into it via a webhook, with zero manual re-entry. No one has to copy numbers from one screen into another.

I'll be upfront about where I sit on this: I'm not a software developer, and I don't claim to be one. My strength is in understanding how systems need to receive and structure data to talk to each other, and building the automation layer - largely through tools like Zapier - that makes that handoff happen reliably, without needing custom-coded infrastructure. I think in webhooks and structured data because that's what makes automations actually reliable, not just convenient.

Where I Simplified - Because the First Version Wasn't the Right One

Here's the honest part. My first instinct was to have each agent hand off with a longer, more detailed instruction block - essentially over-explaining to the next stage what had already happened. It worked, but it was slower to review and added friction exactly where I was trying to remove it.

Once I saw that pattern, I cut it back. Instead of writing out long handoff summaries, I let the file structure itself carry the information - a consistently named, automatically organized Drive folder tells the next person (or the next agent) everything they need just by looking at what's inside it, in order. The instruction block shrank to a single clear line: what's resolved, what to check next. Less writing, same clarity, faster review.

That's the pattern I look for constantly when I build something: the first working version is rarely the simplest one. I'd rather ship it, watch how it's actually used, and then cut whatever turns out to be unnecessary - instead of trying to guess the perfect version up front.

Built to Scale, Not Just to Work Once

The last piece worth mentioning: I didn't build this as a one-off. The same file-naming conventions, the same folder logic, the same three-agent pattern are designed to extend to new use cases, new categories of work, even future agents (I mapped out where an invoicing agent or a customer-response agent would slot into the same structure, without redesigning anything that already works).

That's really the throughline of how I work: understand the real workflow first, build the smallest system that actually solves it, connect the pieces so information doesn't get lost in translation, and keep simplifying once I can see it in action not before.

This is one example of the kind of systems thinking I bring to marketing operations, workflow automation, and AI-assisted business processes.