The small business automated the handoff, not the chat

In a small consulting firm, time is often lost not on difficult analysis but between an email and a system of record. An invoice arrives in a shared mailbox, a manager moves the details into financial tracking, and a payment triggers an internal notification. A client requests new work, and a consultant restates the email in a project card. Each step is simple, yet the chain is fragmented across mail, spreadsheets, messaging, and Jira.

US-based Stratagem works on retail transformation, order management, and supply chains. In a published Google Cloud case, the firm explicitly describes itself as a small business and outlines two internal automations built with Gemini Enterprise.

The first monitors incoming invoices and alerts the team when a payment is received. The second connects client emails with Jira: employees use a conversational interface to create tasks from email content instead of manually copying status and fields. The company also consolidated several separate AI subscriptions into one platform and says it can serve more clients without proportionally increasing headcount.

The source does not disclose operation time before and after deployment, error rates, platform cost, or an independent audit. The 30% reduction in contact-centre volume reported on the page concerns a Stratagem client project, not the firm’s internal email-to-finance-to-Jira workflow. Those facts must not be combined.

The main practical value of the case is not the specific vendor. It is the choice of automation target: the agent sits between systems that already work, turns an unstructured email into a proposed action, and lets the business record be created through a controlled interface.

Why an email is not a ready-to-run command

Email combines data and instructions in one document. The sender, subject, signature, quoted history, attachment, and an incidental phrase can all affect model output. Humans are accustomed to this context; for an agent, the message is untrusted input.

That makes the pattern “new email → LLM → direct API call” dangerous. It fails to separate three entities:

  • event: a new message appeared in the mailbox;
  • proposal: the model extracted fields or drafted a task;
  • action: the system of record accepted a write with defined fields and permissions.

Verifiable boundaries are required between them. A model can propose a title, project, due date, and assignee. Ordinary code must check whether the project is allowed, the user exists, the date is valid, and the service account may create the card. The boundary is stricter for finance: an email about a payment is not a bank statement and must not close an accounts-receivable item on its own.

A controlled-pipeline architecture

A small business can use seven components without building a universal super-agent.

1. A connector receives a new-message notification and stores the event identifier.
2. A filter removes newsletters, auto-replies, and unsupported attachments.
3. Extraction converts the relevant part of the email into typed JSON.
4. A validator checks required fields, reference data, ranges, and business rules.
5. A policy chooses automatic execution, human approval, or an exception queue.
6. A deterministic executor calls only a pre-approved API operation.
7. A ledger links the source email, model version, proposed fields, human decision, and call result.

For Jira, the executor should have permission to create issues only in the required projects. The official REST API returns 201 for a successful create operation and accepts the fields allowed by the issue-creation screen. This is a useful control point: the model does not receive an arbitrary network tool; it produces parameters for one tightly scoped operation.

For the financial lane, it is safer to separate the signal from confirmation. An email or payment-provider notification creates a reconciliation candidate. Amount, counterparty, and payment reference are compared with bank or accounting data. Only a matched record changes invoice status; ambiguity goes to an employee.

Events can be duplicated or lost

The Gmail API can send mailbox-change notifications through Cloud Pub/Sub. The application receives a historyId pointer rather than the complete email, then queries the changes. A watch must be renewed at least every seven days, and the documentation recommends daily renewal. Google also warns that notifications can occasionally be delayed or dropped, so periodic history.list reconciliation is required.

The opposite problem also exists: the broker retries a notification if the handler does not acknowledge it in time. One email can therefore create the same task twice. The safeguard is not a prompt asking the model to avoid duplicates; it is an operation key.

An example key for issue creation can combine:

  • source mailbox identifier;
  • stable messageId or history record;
  • action type, such as create_jira_issue;
  • routing-rule version;
  • target project.

Before calling Jira, the executor checks the ledger. If the key is already complete, it returns the stored result. If status is uncertain after a network failure, the system searches or reconciles first instead of retrying blindly.

The permissions and data that are actually needed

Do not connect the agent to an executive’s personal mailbox or give it a Jira administrator token. Use a dedicated process address, filter with labels, and begin with minimum OAuth access. The first pilot often needs to read metadata and messages, not send mail, delete messages, or manage the whole mailbox.

In Jira, the service account receives Browse Projects and Create Issues only for the selected project. Editing, deleting, workflow transitions, and user administration are separate permissions enabled only for a validated use case.

Additional controls include:

  • attachments pass file-type, size, and malware checks;
  • email HTML is converted to safe text and active content is never executed;
  • quoted history and signatures are separated from the new request;
  • external senders and domains receive a higher risk level;
  • secrets and personal data are redacted before use with an external model;
  • message text can never modify system policy or the tool allowlist;
  • automatic action is capped by amount, task count, and rate.

If correspondence contains commercial terms, personal data, or confidential project information, classification and extraction can run on a local model. Only the connectors to mail and Jira remain external. This hybrid pattern is useful when data must stay inside the perimeter but the business already relies on cloud systems of record.

How to calculate the economics

The Stratagem case does not provide numbers for the internal workflow, so the calculation must be a model based on the company’s own time study.

Measure for two weeks:

  • how many emails genuinely require a task or financial reconciliation;
  • minutes spent reading, transferring fields, and correcting entries;
  • the share of drafts accepted without edits;
  • the share of exceptions requiring a specialist;
  • duplicates and misrouted actions created by automation;
  • licence, integration, support, and model-processing cost.

A useful metric is cost per accepted action:

platform and operating cost plus review and correction time, divided by correctly created tasks or confirmed matches.

Time saved is not automatically business value. Released hours must become additional client work, a faster cash cycle, or fewer overdue tasks. If an employee still rechecks every field for the same amount of time, the agent has only moved the work to a new screen.

A 30-day pilot

Start with one shared mailbox and one Jira project. Do not connect accounting postings or outbound email.

Week 1: collect 100–300 redacted messages, define five task types and required fields, and build a golden set with employee decisions.

Week 2: enable draft mode. The agent extracts fields, but a person creates the issue. Measure completeness, routing accuracy, and edit volume.

Week 3: allow automatic creation for one low-risk type only when every validation passes. Cap operations per hour and provide a kill switch.

Week 4: add the idempotency ledger, missed-event reconciliation, and exception reporting. Compare cost per accepted action with the manual baseline.

The production gate is not an impressive conversation with the agent. It is a stable rate of correct issues on fresh data, no duplicates, constrained permissions, a clear recovery path, and measurable time savings.

The management takeaway

Do not automate “email in general.” Automate one handoff between systems. Let the model read and propose, rules validate, the executor perform only an authorised action, and the ledger prove what happened. This kind of agent helps a small team grow without an administrative tail—and without turning every incoming message into an infrastructure command.