Most agentic AI writing lives in one of two extremes: either abstract ("agents can reason and take action!") or demo-flashy (a shopping assistant, a coding agent). I wanted to write about a case that's neither — a workflow that's genuinely mundane, has been automated with spreadsheets for decades, and shows exactly where an "agent" earns the label versus where it's just automation with better marketing.
The workflow: fixed asset management for small accounting firms. Bear with me, it's more interesting than it sounds.
The problem shape
A fixed asset register tracks long-term purchases (equipment, vehicles, leasehold improvements) and their depreciation over time. The workflow has three recurring failure modes that are worth understanding as a systems problem, independent of the accounting domain:
Classification drift — a transaction needs a decision (capitalize vs. expense) made once, at ingestion time, by whoever happens to be closest to the invoice. There's no forcing function to revisit that decision later.
State that isn't rebuilt from source — the depreciation schedule is typically a spreadsheet that gets edited incrementally rather than recomputed from the underlying transaction log. Any missed edit becomes permanent drift.
No reconciliation loop — the register and the general ledger are two representations of the same underlying reality, and nothing checks that they still agree.
If this sounds familiar, it's because it's the same shape as cache invalidation, or a read model that's fallen out of sync with its event log. Same problem, different domain.
Where "agent" actually applies
Here's the part I think is genuinely instructive: most of what's marketed as an "AI agent" in this space is really automation plus a classification model, and calling it an agent is mostly branding. But there's a real distinction:
Automation: fixed rules, deterministic. "If invoice line item > $2,500 and category = equipment, add to register." This has existed for years and works fine when the rules are stable.
Agentic: the system pulls from multiple heterogeneous sources (AP, POs, card feeds, ERP), makes a contextual classification call against a policy that isn't purely rule-based (does this specific leasehold improvement meet this client's capitalization threshold, given their specific accounting policy), and — critically — it recomputes the full downstream state (schedule, rollforward) from source data every cycle instead of mutating a stored value. That recompute-from-source pattern is what actually earns the "agent" framing here, not the classification step itself.
The reconciliation loop is the other genuinely agentic piece: the system doesn't just sync two data stores, it actively checks whether they agree and surfaces the delta as something a human needs to look at. That's a meaningfully different design than a one-way sync job.
What it doesn't (and shouldn't) do
The policy decisions — useful life estimates, which depreciation method applies, where the capitalization threshold sits — stay with a human. This isn't a limitation to route around with a bigger model. It's a genuine domain-knowledge boundary: the "correct" answer depends on regulatory framework, industry, and a specific client's documented policy, none of which the system should be inferring on its own. A well-scoped agent here is explicit about that boundary rather than quietly guessing.
If you're building anything in this space — not just accounting, but any workflow with the same three failure modes above — that boundary is worth designing in explicitly rather than discovering after the fact when the model confidently gets a judgment call wrong.
The tooling landscape, briefly
For anyone curious about prior art: Thomson Reuters' Fixed Assets CS is interesting mainly because it's built for a fan-out use case (one firm, many independent clients, each with their own policy) rather than the more common single-tenant case (one company, one asset base) that tools like Numeric or AssetAccountant target. The multi-tenant policy-per-client requirement changes the design in ways that are worth thinking about if you're architecting anything similar — it's not just "the same thing with row-level security."
I wrote a longer, accounting-practitioner-focused version of this (less systems-design framing, more "here's how to actually implement this for a client") on my blog if the domain specifics are useful: full article.
Curious if others have run into the same "automation vs. agent" line-drawing question in other boring-but-real back-office domains. Where do you draw it?
Top comments (0)