There's a pattern emerging in how AI is being deployed inside organizations, and most people are describing it wrong.
They call it "AI tools" or "AI assistants" or "AI copilots." These labels are technically accurate but conceptually shallow. They describe the interface, not the architecture. What's actually happening underneath is the assembly of a three-layer stack - Skills, Plugins, and Agents - that works together in a way that's fundamentally different from how software has worked for the last thirty years.
I'm going to explain how this stack works using accounting and finance as the example domain. Not because accounting is glamorous, but because it's the hardest test case. It's rules-dense, error-intolerant, jurisdiction-specific, and full of institutional knowledge that has never been written down anywhere. If the three-layer stack can work in accounting, it can work anywhere.
First: why the old model is breaking
Enterprise software - ERP systems, accounting platforms, CRMs - was built on a premise that is quietly collapsing: that you can anticipate every workflow a user will need, encode it into a fixed interface, and ship it as a product.
The result is software that is simultaneously over-engineered and under-capable. Massive, expensive, and yet constantly requiring humans to do the work the software can't. The accountant doesn't use the ERP to think. They use it to record what they've already thought. The judgment, the expertise, the edge-case handling - that all happens in their head, or in a spreadsheet, or in an email thread.
The three-layer stack inverts this. Instead of building a product that tries to anticipate every workflow, you build a composable system where expertise is encoded once and reused everywhere - by the model, not by hardcoded software logic.
Here's what each layer actually is.
Layer 1: Skills - Encoded Expertise
A Skill is the knowledge layer. It's a structured set of instructions, context, and domain logic that teaches an AI model how to behave in a specific context.
Think of a Skill not as a feature but as a trained practitioner's judgment, made explicit and reusable.
In accounting, this might look like:
A Revenue Recognition Skill that encodes the conditions under which a transaction qualifies as recognized revenue under ASC 606 - including the edge cases, the judgment calls, and the questions to ask when something is ambiguous.
A Chart of Accounts Design Skill that knows how different industries structure their CoA, what common mistakes look like, and how to advise a client setting one up for the first time.
A Go-Live Readiness Skill that understands what a clean migration looks like: opening balances, gap period handling, cutoff dates, pre-flight checks.
A Skill doesn't run on its own. It's not a workflow. It's more like a well-trained colleague who knows a domain deeply and can be brought into any conversation or process where that knowledge is needed.
Skills are reusable across Plugins. A Revenue Recognition Skill might be used inside a month-end close Plugin, a new-client onboarding Plugin, and an audit prep Plugin - all without being rebuilt.
This is important. It means accounting firms can encode their expertise once and deploy it everywhere. The knowledge isn't locked to a specific product. It travels.
Layer 2: Plugins - Supervised Workflows
A Plugin is the workflow layer. It's a multi-step, deterministic process that uses Skills and tools to get something done - with a human nearby.
The "human nearby" part matters. Plugins are designed for work where you want AI doing the execution but a practitioner approving the outputs. They run inside a product surface (think of a desktop or browser environment), they're visible, they're interruptible, and they surface their reasoning at each step.
In accounting, a Plugin might be:
Bank Reconciliation Plugin
- Pull transactions from the connected bank feed
- Match against GL entries using fuzzy matching logic
- Flag unmatched items with suggested categories
- Surface exceptions with reasoning for human review
- Generate reconciliation report on approval
New Client Onboarding Plugin
- Detect missing balance sheet data from the intake
- Ask targeted questions to fill gaps
- Build opening balances based on prior period financials
- Define the cutoff date and gap period strategy
- Run pre-flight verification checks
- Produce a go-live readiness report
In both cases, the Plugin is doing the work. But an accountant is reviewing, approving, and intervening at decision points. This isn't automation in the "replace the human" sense. It's automation in the "the human operates at a higher level" sense.
Plugins are also where accounting firms can package and sell their expertise. A firm that has spent ten years developing a particular onboarding methodology can encode that into a Plugin and deploy it for every client, consistently, at a fraction of the cost.
Layer 3: Agents - Autonomous Execution
Agents are what happens when you take the Plugin model and remove the requirement for a human to be watching in real time.
An Agent has the same components - model, tools, Skills, instructions - but it runs inside a managed cloud environment, executes over minutes or hours, and reports back when it's done (or when it needs a decision it can't make autonomously).
This is the part that requires a real shift in mental model. An Agent isn't a chatbot. It's closer to delegating a task to a capable colleague and telling them to come back when they have an answer.
In accounting and finance, the clearest use cases are the ones that are currently done by armies of junior analysts:
Accounts Payable Processing Agent — Receives invoice documents, extracts line items, matches against purchase orders, flags discrepancies, routes exceptions for approval, posts approved invoices to the GL - all overnight, for hundreds of invoices, without anyone watching.
Variance Analysis Agent — At month-end, pulls actuals vs. budget across all cost centers, computes variances, identifies the top drivers using historical patterns, drafts a plain-English variance commentary, and delivers it to the CFO before the 9am review meeting.
Audit Preparation Agent — Given a list of audit requests, gathers the relevant documents from connected systems, organizes them by request, flags missing items, and produces a draft audit response package - work that currently takes a team several days.
The human's role in each of these isn't eliminated. It's shifted upstream, to defining what the Agent should do and what decisions require escalation, and downstream, to reviewing the output and acting on it.
How the three layers work together
This is where it gets interesting. The layers aren't separate products. They're a composable stack, where each layer depends on the ones below it.
Agent
└── runs Plugins
└── uses Skills
└── calls Tools (MCP, APIs, databases)
A concrete example:
A mid-sized accounting firm serves 40 clients. Every month, each client needs a close package: reconciled accounts, variance commentary, and a management report.
Without the stack: A team of accountants spends the first week of every month manually pulling data, reconciling, writing commentary, formatting reports. It's billable but low-value. Partners hate it. Junior staff burn out.
With the stack:
- Skills encode the firm's methodology for reconciliation, variance analysis, and report writing.
- Plugins give each accountant a supervised workflow for client-specific edge cases that need judgment.
- Agents run overnight at month-end, processing all 40 clients in parallel - reconciling accounts, computing variances, drafting commentary - and surface a review-ready package by morning.
The accountants spend their time reviewing, advising, and handling the 5% of situations the Agents escalate. The other 95% is done.
The firm's headcount doesn't necessarily drop. But their capacity - the number of clients they can serve at a consistent quality level - multiplies.
The deeper architectural shift
There's a reason to explain this stack carefully rather than just calling it "AI automation."
The old model of enterprise software treated business logic as something that lives in the product. The vendor builds the workflow, you configure it, you use it. The expertise is locked in the software.
The new model treats business logic as something that lives in the stack. Firms encode their own expertise into Skills. They build their own Plugins around their own methodologies. They deploy Agents against their own client configurations. The expertise is portable, composable, and theirs.
This changes the competitive landscape in accounting in a way that isn't obvious yet.
The firms that win aren't necessarily the biggest ones. They're the ones that are best at encoding their expertise into the stack - at translating the judgment of their best partners into Skills that every engagement can use. The firms with the deepest domain knowledge, made explicit and deployable, will be able to serve more clients, at higher quality, with the same or fewer people.
The firms that don't figure this out will be competing on price against systems that don't charge by the hour.
What this means for software
The three-layer stack doesn't eliminate software. Accounting still needs a general ledger. Transactions need to be recorded somewhere. The financial data layer still matters.
What changes is everything built on top of that layer. The workflows, the reporting, the client communication, the compliance checking, the onboarding, the analysis - that whole layer is being rebuilt, from scratch, natively inside AI systems.
Not as a plugin to an ERP. Not as an AI feature bolted onto existing software. As the primary way work gets done.
This is the architectural shift that most people in the industry haven't fully priced in yet. The UI, the business logic, and the expertise layer are all moving. At the same time. Into a composable stack that didn't exist two years ago.
The question for accounting firms right now isn't whether to adopt AI. It's whether to encode their expertise into the stack before someone else does it for them.