A model for implementing enterprise AI tooling.

OpenAI, Anthropic, Google, and Microsoft keep moving quickly, and enterprises have bought broad access. But most people still use the tools like faster chatbots, and the value never reaches the work.

The gap is everything around the tools: context, permissions, review, memory, and proof. ATOM makes those pieces explicit, reads the work through six pillars, and shows whether the economics hold. The rest of this paper is how.

Most enterprises have plenty of AI tools. What they're missing is the layer between the tools and the daily work — the part that decides what context the AI sees, what it's allowed to do, what's worth keeping, and how anyone can tell it's working. It helps to see the whole thing as four layers.

The tools on top are rented and the systems below are fixed. The middle is the part an enterprise owns, and it's where the work is won or lost. Today that middle is a tangle: people stitching tools, context, and systems together by hand. ATOM replaces the tangle with clear rules for context, action, review, memory, and proof. The tools above and the systems below exist to serve the work.

ATOM keeps four things separate that tend to get blurred together. When they blur, a method starts to sound like a product, the delivery scaffolding starts to sound like customer software, and tooling gets implied before anyone has agreed there's a real gap.

The framework and the method are always part of the work. The delivery tools keep delivery consistent. The customer software is where it gets interesting, and it earns its place only when the tools already owned and the process leave a real gap, which is most of section 6.

A modern enterprise AI platform already does a great deal: identity and access, admin controls, connectors, analytics, audit, retention, skill and agent directories, runtime controls. The first job is to use those properly, configured against the enterprise's real work, before building anything new. ATOM uses the stack already in place; it doesn't replace it.

Making the environment explicit is the real first job, and it's enterprise configuration design. These are the categories that drive the discovery:

These are the customer's calls to make. An implementation partner can shape, accelerate, pressure-test, and document the work and put it into operation, but the policies, sources, roles, context, approvals, and definition of success stay with the customer.

The engagement's shape depends on scope. A focused team can move in months; a large rollout becomes a multi-quarter program with a full-time internal owner, because the work touches AI platforms, security, data, enablement, engineering, operations, finance, legal, and the business. What stays consistent is the method, and it tends to go in three gears.

Crawl — foundation. Get the first area of the business under review using the tools that are already there. Inventory the tools, work, roles, sources, and context; write the first context and skill/agent contracts; set the security and policy baseline; and take a measurement baseline so there's something to improve against. This is configuration and light records the customer can read and approve: the existing tools, used properly.

Walk — active use. Put real people into the configured system doing real work with configured tools, role and workflow playbooks, approved context, review rules, and a steady enablement rhythm. This is where setup turns into adoption, and where the first real evidence of what's working shows up: receipts, the context and source registries, and the first six-pillar readout.

Run — scale. Where the evidence supports it, go deeper and wider: more teams, more of the work, and the customer-owned software the proof has shown is worth building. This stage is earned by what the earlier work shows.

Two things hold throughout: the customer owns the decisions — policy, sources, roles, risk, and the definition of success — and the pace follows the evidence.

Every engagement starts with a baseline: an honest read of how an enterprise's AI work looks today. It's produced with tooling (section 6), and it becomes the reference point for what improves. Both the baseline and the ongoing work are read through six pillars: the same six that set the baseline, track improvement, and decide where to invest more and where to pull back.

Early on this is a service deliverable and a management rhythm — the readout that tells leaders what to configure next, what to enable, what to stop, and where to put the next dollar. Once an enterprise knows what it wants to operate, the same six pillars become a standing dashboard on its own data. That's a piece of software, and it's the next section.

The method has real software behind it, and it comes in two forms.

The proof product is what the delivery team uses to set the baseline. It maps the people, roles, workflows, tools, sources, connectors, policies, and analytics of a real environment; shows the gaps, missing data, and weak or unsafe evidence; and produces the first six-pillar readout. It makes understanding the environment concrete, fast, and repeatable on every engagement.

The installed product is software the enterprise owns and keeps. It's the persistent version of everything the proof finds: the source-state and context registries, the skill and agent contracts, the receipts and gates, retrieval across tools, approved context where people work, and standing six-pillar reporting, all running on the enterprise's own data. Because every enterprise's systems and data are different, this system is adapted to each one, and that is where the meaningful custom development happens in a major engagement.

Architecturally, both are built from the same set of instrumentation, sitting across the tools already owned and the enterprise's systems:

What it delivers lands in three places: the enterprise gets lower risk and better decisions about where to expand and what to build; the people get faster, easier, safer, higher-quality work through approved context and in-flow support; and delivery gets a repeatable way to run engagements without reinventing the same work each time.

The software is at different stages of maturity: discovery and baseline are in use now, and the installed product is partly built and grows with each engagement. Maturity matters less here than the substance: the software is real, it's architected, and it's a genuine opportunity for custom development tailored to each major engagement.

Custom agents are a real expansion path, but they come later, not first. The first engagement gives an enterprise immediate value: clearer workflows, safer use of context, better enablement, cost visibility, and evidence for management. It also shows where the deeper work pays off: the sources, permissions, integrations, costs, usage, blockers, and business signals that real work depends on. That's what turns "should we build an agent?" from a guess into a decision.

Each of those has to be earned — and an enterprise gets a reason to start before the whole path is obvious.

I want to be straight about where this is proven and where it's still emerging, because it's the most honest and useful part of this.

Knowledge work is proven, and it's where I've spent my time. I've spent years in this work, and the last couple of years architecting AI around it: context engineering, prompt design, connectors, security, guardrails, and the practical setup that helps a person do their actual job. The approach here is mature and straightforward: build the structure around the user so the system supports the work. I use it, my customers use it, and they grasp it quickly.

Engineering is an honest bet, not a finished model. I'm not a career engineer; I haven't spent decades inside large engineering teams, and I won't pretend the gaps in that experience don't matter. I've built and I understand engineering harnesses in small-team development, so I get the concept: a developer working with coding agents needs the right structure around the team, the product, and the work, the same way a knowledge worker does. I think the opportunity is large, and I've done real work framing it. But for my business this is emerging: the highest-value pieces, including what the custom software for an engineering team should be, will only become clear after seeing the work across a large engineering organization. I'd rather say that plainly than claim a finished model I don't yet have.

The principles travel across both: the same primitives sit underneath, and only the domain contracts change.

A practice can standardize how it works; the customer's answer stays their own.

What can be standardized: the intake for a first engagement, the baseline dataset, the contract structure for work, context, action, review, and evidence, the existing-tools-first approach, the enablement rhythm, the receipt and proof model, the six-pillar readout, the expand/build/stop decision, the delivery tools that keep it consistent, and the language for what's proven versus what's emerging.

What stays specific to each customer: the work that matters first, the approved tools, the source hierarchy, the risk boundary, the proof their buyer needs, the governance cadence, the appetite for owning software, and the path into custom workflows or agents.

That's what keeps the work repeatable and still theirs.

ATOM is a way to implement enterprise AI tooling. It starts with the environment an enterprise already has, configures the tools against real work, makes context and action reviewable, reads the work through the six pillars, and uses that evidence to decide what to expand and what to build.

The aim is to help an enterprise make its AI something the business controls and its people use on the work that matters, then build the software that makes that last.