Building an AI-assisted agency workflow: from support email to invoice

At a glance

This hypothetical guide explains an AI-assisted agency workflow for developers, designers, and small agencies. It follows one fictional support request from email through approval, staging, verification, and invoicing, then outlines the equivalent path for new projects.

The examples use synthetic information. They do not describe a particular business or an independently tested agency platform.

Three layers, three responsibilities

n8n coordinates the process: receive events, create tickets, wait for approval, and resume jobs. Persistent state connects each request to its proposal, approval, and execution history.

The AI runtime interprets the request: retrieve approved context, propose an investigation, and prepare structured tool requests. Model output is a proposal; application code validates it before execution.

MCP exposes controlled tools: diagnostics, staging, repositories, and business-system integrations. MCP standardizes tool and context exchange; the host application and connected services enforce access. The Model Context Protocol architecture overview explains that separation.

A fictional support request: shipping disappears

A demonstration WooCommerce store offers a Standard Delivery option. Adding a product in the synthetic bulky-demo shipping class makes that option disappear.

In this scenario, a conditional shipping extension has an explicit rule that hides Standard Delivery whenever that class is present. The rule was applied too broadly. The client's intended policy allows these items in one domestic zone but excludes them elsewhere.

This is a documented type of extension behavior: WooCommerce Conditional Shipping and Payments: shipping-method restrictions describes conditional exclusion of shipping options. It is not a claim that a blank shipping-class cost in core Flat Rate automatically hides a method. The fictional configuration has not been run on a WooCommerce demo store.

1. Verify the request and create one ticket

The receiving mail service supplies SPF, DKIM, and DMARC results. Read those trusted results, not a sender-supplied Authentication-Results header. Domain authentication helps identify spoofing; it does not prove authority to modify a website. Sensitive changes require confirmation through an authenticated client portal or a previously verified channel. Forwarding-related uncertainty goes to review. Google's email sender guidelines explain SPF, DKIM, and DMARC.

Match the sender to an authorized contact. Use the message ID and client identity to create a unique work record.

2. Gather evidence before proposing a change

Read-only tools retrieve the applicable zone, method configuration, and extension restrictions. Reproduce the affected cart on staging and compare it with a standard-product cart.

The explicit exclusion rule explains the missing option. The agent proposes narrowing that rule to the intended destinations. It does not invent a plugin defect or disable every restriction to make checkout pass.

3. Bind approval to a specific proposal

The service agreement determines whether the task is included or billable. A proposal records the rule to change, affected zone, expected behavior, price or spending cap, and acceptance tests.

Client approval identifies that proposal's version. A material change to scope requires fresh approval. Estimates remain estimates; actual labor and fixed-price billing follow the agreement.

n8n's human-review guide for AI tool calls explains how to pause a proposed tool call for review. The application still needs to bind that decision to the correct client and scope.

4. Stage the correction and test its boundaries

Record the original configuration and a recovery procedure. Apply the proposed rule change on staging, then check:

Test cart and destination	Expected result under the fictional policy
Standard product, permitted zone	Standard Delivery remains available
Bulky product, permitted zone	Standard Delivery becomes available
Mixed standard and bulky cart, permitted zone	Standard Delivery is available
Bulky product, excluded destination	Standard Delivery remains hidden
Unsupported destination	No newly enabled shipping option

The client defines the expected policy. Tests must establish both the intended correction and preservation of valid restrictions.

5. Deploy, verify, and report

After the required technical approval, apply only the agreed change and repeat the relevant checks against the live configuration. A failed check stops the process and triggers recovery or escalation.

The completion report records the configuration change and test evidence. The accounting integration uses the approved billing terms and a unique work reference. Invoice creation, invoice delivery, and payment receipt are separate states; the accounting or payment system supplies payment status.

The corresponding new-project path

A new website starts with discovery rather than diagnostics:

Inquiry → requirements → questions and revisions → agreed scope
        → staging build → testing and client acceptance
        → authorized launch → handover and billing milestones

A requirements agent extracts objectives, audiences, pages, features, integrations, and content responsibilities, marking unknowns for clarification. The client approves a versioned scope and acceptance criteria before implementation.

Coding and design tools then support the staging build. Review covers responsive behavior, accessibility, access control, error states, and the actual user journey. A template-based brochure site and a sensitive-data application require different acceptance processes. A polished preview alone is not a completed project.

Controls and failure handling

Use one set of operational controls across both paths:

Failure or uncertainty	Control and response
Unverified sender or ambiguous approval	Confirm authority and bind approval to the exact proposal version
Duplicate event or restart after partial work	Persistent job state, atomic uniqueness checks, and reconciliation before retry
Two jobs changing one site	Per-site locks and serialized deployment
Wrong diagnosis or staging/live mismatch	Reproducible evidence, release checks, and operator escalation
Instructions hidden in email, logs, or tool metadata	Treat retrieved content as untrusted; validate actions outside the model
Access to another client's resources	Client isolation and narrowly scoped credentials
Provider outage or exhausted budget	Timeouts, cost caps, a held queue, and an accountable operator
Failed tests or unavailable recovery	Block deployment; restore only through the recorded recovery procedure
Incorrect billing classification	Hold the invoice for review against the agreement

Audit records connect the request, evidence, approvals, actions, and result. They also support evaluation when a model, prompt, or tool changes.

Security, data, and responsibility

Review the tool surface

Tool poisoning occurs when malicious tool descriptions or metadata attempt to influence an agent. Use reviewed MCP servers, restrict exposed capabilities, and review changes to server code and tool definitions. A convincing tool description is not an authorization boundary.

Keep secrets outside prompts and ordinary logs. Separate read access from change access, clients from one another, and staging from production. The MCP security best-practices guide covers protocol-specific risks and authorization protections.

Map data sent to model providers

List the email contents, log extracts, database fields, and attachments that leave the environment. Prefer minimal, redacted diagnostics over entire databases.

Review provider terms for retention, training use, subprocessors, and processing locations. Determine which data-processing agreements and transfer safeguards apply to the engagement. Local hosting does not automatically establish privacy compliance. The UK Information Commissioner's guidance on AI and data protection provides one jurisdiction-specific starting point.

Assign an accountable operator

Contracts need to address approval scope, incident response, recovery duties, and liability allocation. Professional or cyber insurance may be relevant. Backups reduce operational risk; they do not decide who bears a loss. The actual engagement needs appropriate contractual review.

Choose models by pipeline stage

Evaluate models against a fixed set of representative tickets, including denied approval, missing context, misleading logs, and tasks that require escalation.

Stage	Candidate approach	What to measure
Category labels and field extraction	A smaller model with a narrow schema, initially under review	Schema validity, field accuracy, escalation on missing data
Searching approved documentation	Deterministic retrieval, with a smaller model for summaries if it passes evaluation	Source fidelity, omitted constraints, latency
Diagnosis and patch proposals	A model demonstrated to handle the relevant code and tool tasks	Correct tool and arguments, reproducible fixes, unsafe proposals, reviewer correction time
Completion summaries	Templates populated from verified records; optional model editing	Unsupported claims, factual omissions
Permissions, billing arithmetic, and release gates	Deterministic application rules	Policy enforcement and accounting correctness

Calculate cost per correctly resolved ticket, including model calls, tool execution, retries, and human review. A cheaper model that generates more correction work can cost more overall.

A smaller model earns a role through measured results, not its label. Neither a small nor a large model supplies its own authority to deploy. Anthropic's Building effective agents: workflows versus agents describes the architectural tradeoffs behind starting simply.

Inspect a small workflow example

Download the synthetic n8n workflow JSON and read its instructions and limitations.

It contains a Manual Trigger and a Code node with eight synthetic cases: valid approval, unverified identity, denied approval, an old proposal version, the wrong client, failed staging checks, missing recovery readiness, and a duplicate event.

The successful case returns ready_for_human_review. It never deploys, sends email, or creates an invoice. No credentials, model, or MCP connection are included. Identity and test evidence are fixture values, not live verification.

Validation: the JavaScript ran locally under Node.js and all eight expected outcomes passed. JSON structure and connections were checked. Import and execution inside n8n have not been tested. Duplicate detection lasts only within one run; a production implementation needs durable state and atomic controls. This artifact demonstrates gate logic, not an end-to-end agency platform.

n8n's workflow export and import documentation explains importing JSON from a file.

Start with one bounded workflow

You do not need to reproduce an entire agency first.

Start with synthetic tickets and draft responses. Add read-only diagnostics, measure outcomes, and introduce reviewed staging changes only after the evidence supports them. Connect billing after authorization and delivery records are dependable.

For developers whose roles are shifting, this creates a practical learning path: own one useful process, establish that it works, and expand deliberately.

For a scoped discussion about WooCommerce reliability, integrations, or automation, contact mfaruk.com. Follow future technical guides through the blog RSS feed.