How an AI Employee Actually Works: The Architecture Behind a Sovereign AI Operation Engine

Why the Architecture Question Matters Before You Buy

Most Australian SMB owners we talk to start with the same question, "how does this thing actually work?" It is a fair question. A chat window does not tell you very much, and the moment you put real client data into a tool, the architecture stops being an academic curiosity and starts being the thing that protects you, or doesn't.

Two practices can buy something called an "AI assistant" and end up with wildly different products. One might be a multi-tenant SaaS pointing at an overseas model with a shared memory pool. The other might be a single-tenant AI Operation Engine in AWS Sydney, with isolated memory, an immutable audit log and explicit approval gates. Both will demo nicely. Only one survives a CPS 234 conversation with your bank or a Tax Practitioners Board enquiry.

This post walks through the architecture of an Agentive AI Employee from the bottom up, in plain English. Six layers, what each one does, and why each matters for an Australian SMB owner trying to make a sensible buying decision. For the wider definition of the product itself, see what is an AI Employee.

The Six Layers, at a Glance

Think of an AI Employee as a building. The model is on the top floor doing the thinking. Underneath it sit the layers that turn thinking into safe, repeatable action. The whole building sits on Australian soil with one tenant inside, and a human concierge with the keys.

Layer 0: The Large Language Model (the Brain)

At the very bottom of the stack sits a large language model. This is the part most people are familiar with: the thing that reads text and produces text. It is the reasoning core. When you ask the dedicated AI to summarise a contract or draft a client email, the LLM is doing the linguistic heavy lifting.

A few practical points worth knowing as an SMB owner:

• • We use frontier-class models from leading providers, accessed through endpoints that keep inference inside Australia.
• • The architecture is deliberately model-agnostic. When a new model clears our internal benchmarks for finance accuracy, response latency and Australian residency, we route work to it.
• • The model itself does not remember anything between requests. Memory, which we cover in Layer 2, sits outside the model and is fed in deliberately.

The most important thing to understand about the LLM layer is that it is necessary, but it is not the product. ChatGPT is just an LLM with a chat box. An AI Employee is everything that sits on top of the LLM to make it safe, governable and actually useful to a business.

Layer 1: The Tools and Skills Layer

The next layer up is what turns a model from a clever conversationalist into something that can actually do work. We split it into two ideas.

Tools

A tool is a single capability that the AI Employee can call. Things like "create a Xero invoice", "send a Gmail message", "look up a HubSpot contact", "publish a WordPress draft", "place a phone call via Twilio", "read a row from a Google Sheet". Each tool is a defined function with a contract: this is what you have to give me, this is what I will give you back, this is what I am allowed to change.

The model sees a catalogue of available tools and decides which to call. Crucially, the model cannot invent new tools. It can only call what has been deliberately wired in. That sounds like a small thing. It is actually the difference between an AI that surprises you in good ways and one that surprises you in bad ways.

Skills

A skill is a curated bundle of tools, prompts, policies and memory that turns raw capabilities into a business outcome. Our Finance Skill, for example, packages Xero tools, bank-feed parsing, GST coding rules, a BAS workflow and a set of approval prompts into one named role. Our Marketing Skill packages WordPress, LinkedIn, image generation and SEO best practices.

If tools are verbs, skills are job descriptions. A bookkeeping practice does not want to wire up Xero from scratch; they want to hand the bookkeeping skill to a dedicated AI and watch the BAS draft appear with the right approval gates. Skills are what make that possible without engineering work on your side.

Layer 2: The Memory Store

A real employee remembers things. They remember which client is allergic to spreadsheets. They remember that the November BAS was lodged late because the bank feed broke. They remember the wording you prefer when chasing overdue invoices. Without memory, an AI is forever a new starter on day one. That is exhausting to work with and unsafe to trust with real data.

The memory store inside an Agentive AI Employee has two parts:

• • Structured memory. Facts, decisions, preferences and processes, segmented by topic (clients, vendors, workflows, internal team). Timestamped. Editable by you.
• • Vector memory. A searchable index of unstructured text, emails, file notes, past conversations, that the AI can recall by meaning rather than exact keyword.

Both live inside your single-tenant instance. There is no cross-customer memory pool, and no shared embeddings index. If you decommission your AI Employee, the memory store is deleted with the instance. If you correct a memory ("Acme Pty Ltd uses calendar quarters, not financial quarters"), the correction is timestamped and the AI uses the corrected version from that moment forward.

Layer 3: The Audit Log

Memory tells the AI what to do. The audit log tells you what the AI did. For finance work, this is the layer that turns a clever toy into something a regulated practice can actually use.

Every meaningful action gets written to an append-only log: the prompt the AI was given, the tool calls it made, the inputs and outputs of each call, any human approval, and a timestamp. You can view, search, export and present the log at any time. When your tax agent asks "who lodged this BAS draft and on what basis", the audit log has the answer in seconds.

Append-only matters. A log you can edit after the fact is not really a log. The audit log on an Agentive AI Employee cannot be silently rewritten, by you or by us. That is a deliberate design choice. It is also what makes the product align cleanly with APRA CPS 234 expectations around accountability and ASIC RG 255 expectations around record-keeping for the financial advice and assistance sector. For our walk-through of how that lands in practice, see how it works for financial advisors using a dedicated AI.

Layer 4: The Single-Tenant Server

Most modern SaaS products are multi-tenant. One application, many customers, shared database, shared queue, shared cache. It is the cheapest way to run software at scale. For most software it is also fine.

For an AI that holds your client data, your finance memory, your integration credentials, your contracts and your phone-call transcripts, multi-tenant raises questions we do not want to be answering on a Tuesday afternoon. Whose memory is in this request's context window? Did the wrong client just get referenced in a draft email? Is the audit log shared? Are the bank-feed credentials in a shared key vault?

Single-tenant removes the question. Each Agentive AI Employee runs on its own dedicated server. Your memory store, your audit log, your queue, your integration credentials and your model context window are all isolated to your instance. Nothing is shared with any other customer. If a future customer joins the platform tomorrow, your environment is untouched.

This is more expensive for us to operate. We think it is the right call for the kinds of practices we serve. A bookkeeper holding 200 clients' Xero credentials should not have their AI sharing process space with anyone else's, full stop.

Layer 5: The Australian Hosting Region (AWS Sydney)

The single-tenant server itself lives in AWS Sydney (the ap-southeast-2 region). Storage, compute, queue, memory store, audit log, scheduler: all inside Australian infrastructure boundaries. When the AI Employee calls a model for inference, it goes to an endpoint with Australian inference. When it calls an integration, the call is logged on the Australian audit trail.

For finance-adjacent businesses this is not a marketing line; it is the answer to a real question their bank, their regulator or their PI insurer will eventually ask. We made the architectural calls early so that the answer is "yes" rather than "let me check".

Layer 6: The Human Governance Overlay

Sitting around the whole stack is the layer that is the easiest to forget and the most important to get right: humans.

A managed AI Employee from Agentive is not "set and forget". We configure approval gates on sensitive actions, so the AI drafts a BAS lodgement but does not file it without sign-off. We provision and rotate integration credentials. We monitor the audit log for unusual patterns. When the model misbehaves, our operations team is on the hook for the fix, not your bookkeeper. When a regulator asks for evidence, we know exactly where to point them inside the log.

This governance overlay is what closes the gap between "a powerful AI" and "an AI you can actually deploy in a regulated environment". You can build the bottom five layers yourself if you have the engineering team. You cannot easily build the sixth one alone.

How the Layers Cooperate on a Single Task

Architecture diagrams are easier to understand once you walk a real request through them. Take a Sydney bookkeeping practice asking their AI Employee to "draft the Q4 BAS for Acme Pty Ltd". Here is what happens, layer by layer.

1. Layer 6. The request arrives through chat. The governance overlay checks that the user is authorised and that BAS prep is enabled on this skill set.
2. Layer 5. The request is processed entirely inside AWS Sydney. Nothing has left Australia yet.
3. Layer 4. Routing finds the customer's dedicated single-tenant instance. Nobody else's data is in scope.
4. Layer 3. An audit log entry is opened: "Q4 BAS draft requested for Acme Pty Ltd at 09:14 AEST, by user X."
5. Layer 2. The memory store is queried for everything the AI knows about Acme: prior adjustments, GST coding quirks, the preferred review checklist.
6. Layer 1. The Finance Skill is loaded. Tools include "list Xero transactions", "categorise by GST", "draft BAS summary", "create PDF".
7. Layer 0. The LLM is given the memory, the tool catalogue and the task. It plans the steps, calls the tools, and produces a draft.
8. Back up the stack. Each tool call is logged. The draft and assumptions are returned to chat. The bookkeeper reviews, asks for tweaks, and signs off. The sign-off itself is logged.

End to end, the whole sequence might take 90 seconds. The trick is that every one of those 90 seconds is on Australian soil, on your dedicated instance, with every step recorded. That is the difference between "AI-assisted bookkeeping" and "AI-assisted bookkeeping I am willing to put my registration on".

What This Architecture Means for Compliance

We get asked, often by accountants and advisors who have read CPS 234 cover to cover, what specifically about the architecture lets us claim alignment with Australian regulatory expectations. Three concrete things.

• • Data residency. Storage and inference inside Australia means a confident answer to the data-sovereignty question regulators and bank-facing clients increasingly ask.
• • Defensible audit trail. The append-only log gives you the evidence trail that ASIC RG 255 and the Tax Practitioners Board both expect for AI-assisted work.
• • Single-tenant isolation. No cross-customer memory means no awkward confidentiality argument with your PI insurer or your professional body.

None of this removes your professional obligations. An AI Employee does not absolve a tax agent or financial adviser of their personal responsibility for the work. What it does is give you a product whose architecture supports those obligations rather than fighting them.

Where Most Off-the-Shelf AI Tools Stop

A lot of products in the market today are good at one or two layers and silent on the rest. That is fine for some buyers; it is a real problem for an Australian SMB with regulatory exposure.

The right question for your practice is not "which product has the smartest model"; the model layer has largely commoditised. The right question is "which product gives me the upper layers I cannot easily build myself". For most Australian finance-adjacent SMBs, that is a much shorter list.

The Honest Conclusion

After two years of building this stack for Australian practices, the honest summary is that the AI Employee is deeply unglamorous engineering. The brain is exciting. The other five layers are not. They are plumbing, audit trails, approval gates, region selection and operations runbooks. None of it would make a good keynote slide. All of it is the difference between an AI you tinker with on weekends and an AI you put your professional registration behind on a Monday morning.

If you are evaluating products for your practice, ask the vendor to walk you through their version of the six layers. The answers will tell you whether you are buying a chatbot, a multi-tenant SaaS workflow, or a real AI Operation Engine that can carry weight in an Australian regulatory context. That is what we have built, and we will happily show it to you on your own demo instance, layer by layer.