Dave Bowatta

Intelligent business architecture

Your business should not depend on youto keep everything connected.

I design AI-enabled operations around how your business already works, so the systems, knowledge and people connect and you stay in control.

A diagram in two states. First, you sit in the middle of customers, email, quotes, scheduling, the team, suppliers, invoices and reports, every request passes through you and a queue builds. Then an operating layer connects those parts to each other, the work moves between them directly, and you are connected by one line for decisions.

How an intelligent operating architecture is assembled

  1. 01 · The owner

    You built the business.

    Somewhere along the way, you became the system running it.

    Every question, every approval, every exception routes through one person. That works until it is the thing holding the company back.

  2. 02 · Software is not the system

    Most businesses do not have a software shortage.

    They have a connection problem. The CRM does not tell the accounting system anything. The scheduling tool has never heard of the helpdesk.

    So a person becomes the integration layer, reading one screen and typing into another all day.

  3. 03 · The digital foundation

    Before a business can become intelligent, it has to become connected.

    Departments, and the systems and records that belong to them, mapped as they actually work rather than as an org chart.

    From here, digitalisation is part of how the business runs, not a software project.

  4. 04 · Connected information

    AI is only as useful as the context it can safely reach.

    Customer records, contracts, SOPs, policy, product data, transaction history, the job files. Most of it already exists. Almost none of it is reachable from one place.

    Nothing here is copied into a model. It stays where it lives, under the permissions it already has, and is reached through an indexed layer: retrieval, a warehouse with one definition per number, and an audit log for everything touched.

  5. 05 · What a model is

    A model is the reasoning engine.

    It interprets, classifies, summarises, drafts and reasons over whatever it is handed. That is the whole of it.

    On its own it knows nothing about your company, and it cannot do anything to your systems.

  6. 06 · Retrieval

    The model does not need your company in its memory.

    It retrieves what it needs, when it needs it, and cites where the answer came from. The industry calls this retrieval-augmented generation.

    The distinction matters: the model reasons, retrieval decides what it is allowed to read.

  7. 07 · From model to agent

    A model reasons. An agent pursues a goal.

    Give the model instructions, context it may read, tools it may use, memory of what it has already done, permissions that bound it, and something to achieve. That assembly is an agent.

    It operates under a written scope of authority, with a person signing off anything that matters.

  8. 08 · Skills

    Capabilities are built once and shared.

    Retrieval, classification, extraction, drafting, policy checking, forecasting. Each is a capability, not a department.

    One skill serves several agents. That is why this is architecture rather than a pile of separate automations.

  9. 09 · Tools and interfaces

    Intelligence becomes operational when it can safely touch the systems where work happens.

    Agents reach applications through controlled interfaces: APIs, connectors, and increasingly MCP, one of several ways to expose tools and context to a compatible system.

    Every interface is scoped: this one may read, that one may write, this one always stops for a person.

  10. 10 · Coordination

    No single agent needs to know everything.

    An orchestration layer routes a business event to whichever specialists it concerns, in the right order, and keeps the record of what happened.

    Coordinated specialists are more reliable than one general assistant with vague responsibility for the whole company.

  11. 11 · The whole architecture

    One company, working as a system.

    It is an operating architecture made of departments, agents, shared capabilities, the systems where work happens, and the company's own knowledge, all connected, scoped and observable.

    Each element on screen maps to a process a business like this actually runs.

  12. 12 · One business event

    A new customer arrives. Follow it.

    The customer agent opens the record. Compliance checks the terms. Sales prepares the quote. Operations reserves the capacity. Finance raises the invoice. Reporting picks it up on the next cycle.

    One event, a dozen system interactions, a handful of judgements, and exactly one step that waits for a person. The numbers are illustrative, not a promise about your business.

  13. 13 · Governance

    Every agent works inside limits.

    Every agent runs inside a boundary: what it may read, what it may write, what it must escalate, and what it may never do without a person saying yes.

    Every action is logged against an identity. If you cannot say who did something and under what authority, the system is a liability.

  14. 14 · What changes for you

    You did not build a business to become its operating system.

    The work still happens. It no longer routes through one person. What reaches you is what requires you: strategy, approvals, exceptions, performance, the decisions only you can make.

    The aim is to remove the coordination overhead, so people spend their time on the work only a person can do.

Drag · pinch or Ctrl + scroll to zoom · click to isolate

Where it belongs

Not every problem needs AI.The work is deciding where it helps and where it does not.

A great deal of what looks like an AI problem is a deterministic one. A rule, a form, a scheduled job or a properly connected integration will beat a model on cost, latency and predictability, and it will usually still be working in five years.

AI is worth using where the input is unstructured, where judgement is required, or where the alternative is a person reading something and retyping it somewhere else.

A squared stack of paper invoices beside a document scanner feeding a single sheet, on a dark desk.

01Use a rule

The answer is already known.

Input

Fixed fields with a known answer

Cost to run

Close to nothing

Over time

Behaves the same way for years

When it fails

Loudly, on the case nobody wrote a rule for

Invoice reminders · Reorder points · Approval routing

An overhead spill of mixed paperwork on a dark desk: printed emails, forms on clipboards, sticky notes and a phone.

02Use a model

Someone has to read it first.

Input

Emails, PDFs, forms and calls

Cost to run

Paid per request, so volume matters

Over time

Needs checking, and limits on what it may do

When it fails

Quietly, with a confident wrong answer

Request triage · Quote drafting · Document search

Everywhere else, the simplest mechanism that solves the problem is the correct architecture.

Infrastructure

Where the intelligence runs is part of the architecture.

  • 01

    Cloud

    Fastest to stand up, frontier capability, least infrastructure to own.

    1. Business
    2. Secure API
    3. Frontier model

    Fits when

    • Rapid deployment
    • Frontier reasoning capability
    • Variable or unpredictable workloads
    • Little appetite for owning infrastructure

    Data leaves your environment. That is a governance decision before it is a technical one.

  • 02

    Hybrid

    Private information stays put. Only what needs frontier reasoning leaves.

    1. Private environment
    2. Local model & retrieval
    3. Controlled router
    4. Frontier model

    Fits when

    • Sensitive records with routine workloads
    • Local retrieval over private knowledge
    • Cost control on high-volume tasks
    • Selective escalation for hard reasoning

    The router is the architecture. Get the escalation rule wrong and hybrid ends up as cloud.

  • 03

    Private / on-premise

    Inference, retrieval and storage all inside your own network.

    1. Local network
    2. AI compute
    3. Local model
    4. Vector & storage
    5. Integrations

    Fits when

    • Data residency or contractual isolation
    • Predictable, steady workloads
    • Internal knowledge that cannot leave
    • Environments with restricted connectivity

    It means owning the hardware, capacity planning and maintenance, which is worth it when the constraint is real.

I am model-agnostic. The review covers local AI hardware, storage, model hosting, retrieval, networking and cloud APIs, and which work belongs where.

Applied

The same architecture, applied by industry.

Renewals arrive in waves, every file needs documents chased, and the compliance record has to survive an audit years later.

Departments

  • New business
  • Servicing
  • Claims
  • Compliance
  • Finance

Agents

  • Renewal agent
  • Document agent
  • Claims intake agent
  • Compliance agent
  • Reporting agent

Systems

  • Broker management system
  • Email
  • E-signature
  • Carrier portals
  • Accounting

Knowledge

  • Policy records
  • Carrier wordings
  • Client correspondence
  • Regulatory guidance

Representative workflows

  • Renewal detected → exposure review → market submission → comparison prepared → broker presents
  • Claim reported → coverage checked → carrier notified → client kept informed

Governance

  • Client data never leaves the brokerage boundary
  • Every recommendation traceable to a policy wording
  • Full audit trail against a named licensed broker

Always a person

  • Any advice given to a client
  • Binding cover
  • Anything touching a claim outcome

Most of a servicing team's week goes on chasing documents and re-keying the same client detail into three portals.

The same approach applies to accounting firms, retailers, cafés and wineries.

How the work runs

Architecture first. Implementation second. Governance throughout.

  1. 01

    Discover

    Understand how the business actually runs: the workflows, the bottlenecks, the information, and the decisions that currently need you.

  2. 02

    Map

    Write down how the work actually runs. Where work starts, who owns each handoff, which steps are coordination rather than judgement.

  3. 03

    Architect

    Design the systems, intelligence, permissions, integrations and infrastructure, and decide where intelligence does not belong.

  4. 04

    Build

    Implement the connections, retrieval, agents, workflows and interfaces, against the model rather than against a feature list.

  5. 05

    Govern

    Define access, approvals, escalation, logging and boundaries before anything is allowed to act, not after.

  6. 06

    Optimise

    Improve the architecture as the business changes, and retire the parts that are no longer used.

Next step

Start with how yourbusiness runs today.

An architecture review maps the systems, information, workflows and decisions your business depends on, then identifies where integration, automation and intelligence would save real time, and where they would not.

If it gets built, by Auxcura or your own team, I stay involved until it is running.

Architecture review

Opens your mail client with the details filled in. Nothing is stored on this site.