Design Reference for Enterprise AI Maturity

David Deitsch
Technology Workflows Architect | AI Strategist

One of the most common questions I hear about Agent-to-Agent communication is simple: Why do I need two AIs? Isn’t one enough?

For decades, enterprise systems have spoken API to API. It’s a language built on structure—parameters, fields, syntax. APIs are reliable, but brittle. One wrong input and the conversation breaks down.

AI agents changed that. Instead of forcing users to know the right command or fill in the right form, agents can handle agentic input: natural language, messy intent, incomplete context, even incorrect syntax. The agent interprets what the user means, then translates it into structure the system understands. That shift, from form to conversation, is what makes AI agents useful in the first place.

So why would we ever need two of them? Because no single agent understands everything.

In Before the Agent Acts, I discussed the need for Source Data Control,especially the importance of understanding the target schema. An agent fluent in IT service tickets doesn’t automatically know the schema of a monitoring platform. An agent built for HR data doesn’t automatically understand network infrastructure. Each is strong in its own domain, but blind outside it.

That’s where Agent-to-Agent (A2A) comes in. Imagine one agent is great at pulling intent from messy service requests, while another is built to execute changes in a complex IT system. On its own, the first agent can’t act. On its own, the second agent can’t interpret. But if the output of one becomes the input of the other, the chain works. One interprets, the other executes.

This isn’t redundancy. It isn’t wasted expense. It’s orchestration by design.

And it solves a problem APIs never could: preserving intent. APIs pass perfectly structured data, but they strip out the nuance that got you there. Agents, by contrast, have the ability to carry the context forward. The conversation doesn’t get flattened into fields; it moves intact from one intelligent system to another.

The results are smoother handoffs, faster workflows, and a foundation that scales. Instead of pretending one AI can know every platform and schema, we let each agent do what it does best, then connect them in a way that mirrors how people already collaborate.

So why (and when) two AIs? Because the output of one is the natural input of the other. Together, they extend the value of conversation beyond the human interface, into the fabric of machine-to-machine interaction. That’s not duplication. That’s the next step beyond APIs.

Around here, however, we don’t look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we’re curious...and curiosity keeps leading us down new paths. - Walt Disney (attributed)

Part of the Deitsch’s DREAM Enablement Series

Design Reference for Enterprise AI Maturity

David Deitsch
Technology Workflows Architect | AI Strategist

Executive Summary

Everyone wants AI to take action. But few pause to ask: does it even know what it’s acting on?

In the rush to build agentic workflows—self-healing systems, AI-driven automation, real-time response—we often skip the first question an engineer would ask: What are the components? Where do they live? How are they connected? And what are their authoritative states

The DREAM model defines the progression toward execution: Conversation → Suggestion → Execution (https://deits.ch/DREAM). And Stage 2—Suggestion—has emerged as the weak link preventing true autonomy.

So, we face a decision: Either improve the model’s ability to Suggest—or accept that it cannot Suggest, and work around that limitation. Because Execution without Conversation or Suggestion… is just workflow.

Given this, the path forward becomes clear: How do we help AI improve its suggestion capabilities?

This essay introduces three Foundational Data Capabilities every enterprise must strengthen to enable reliable AI-driven suggestions:

1. Source Data Control – Structured documentation of how things are supposed to work.

2. Active Data Control – Near real-time, refreshed visibility into how things actually are.

3. Enterprise Trust (Preview) – A first look at the deeper trust systems required to govern what data the AI should choose, which sources it should prefer—and most importantly, why.

Foundational Capability 1: Source Data Control

In most enterprise environments, the data layer underneath automation is brittle or missing entirely. The Configuration Management Database (CMDB) is incomplete or inaccurate. Data population is delayed or shallow. System relationships are either manually drawn—or not captured at all.

That doesn’t stop the ambition. Teams push forward with AI prototypes, hoping language models can leap over messy data and somehow land on solid ground.

They won’t. AI doesn’t remove the need for system awareness—it amplifies it.

Product documentation, SOPs, CMDB schemas—this is how things are supposed to work. If an AI's Suggestions are built on outdated or fragmented descriptions of the environment, even basic logic can break. This isn’t just about storing documents—it’s about ensuring structured, navigable, and trustworthy representations of expected behavior and configuration.

Take for example this CMDB Schema:

If an AI is expected to serve as a conversational interface, it must deeply understand three things:

1. English (to engage the user)

2. The platform’s operational schema (e.g., where credentials and history are stored)

3. The target schema (e.g., the server, instance, or app the action will affect)

Without this multi-perspective understanding—user, platform, and target—the AI cannot generate accurate Suggestions.

Take Microsoft Copilot. We often assume that because it’s embedded, it understands the application. But, in reality, Copilot cannot even reliably format text inside Word. When asked, it suggests how you might do it, but not how it might do it for you. Why? Likely because it doesn’t understand Word's internal schema—its data model, formatting engine, or interaction boundaries.

Copilot can read and write English. But that’s not the same as understanding Word.

This translation challenge—between interface, system, and execution context—is where Suggestion often breaks. And in the enterprise, the cost of broken Suggestions is high.

So, the first step is clear:

Enterprises must give their LLMs access to correct, current, and structured source data—across every domain where they expect the model to communicate, interpret, or act.

Foundational Capability 2: Active Data Control

Active data in the enterprise is not one monolithic source—it comes in layers. To make this practical, we can break it into two categories: Data Foundations and Just-In-Time (JIT) Data.

JIT Data takes two common forms:

• Streaming into a platform in near real-time

• Or retrieved at runtime in response to a specific question the static dataset can't answer alone

In a prior demonstration, we explored this concept using a MAC address to locate a physical device. You can view that example here:

In that scenario, we utilized network MAC address table data—already populating daily into the CMDB—as the active data foundation the agent could search. That worked, because the MAC address belonged to a wired device.

But if the MAC address had belonged to a wireless device, that same strategy may have failed. A Just-In-Time (JIT) query to the wireless controller would have been far more effective.

Daily snapshot data may be sufficient for wired infrastructure. But wireless usage introduces volatility—devices move, disconnect, or roam—which often demands real-time visibility.

Now that we’ve seen both wired and wireless scenarios, let’s step back and extract a more general principle: Active Data Strategies must align with the AI’s three spheres of understanding—user, platform, and target.

To build a reliable Platform Data Foundation, the best starting point is often the platform manufacturer’s own data population mechanism. In my experience, two things tend to hold true:

1. At scale, buying is cheaper than building

2. Vendors populate their own schemas substantially better than anyone else

Yes, most tools can extract the data. But the careful, schema-aligned mapping required for AI to understand the system—that level of precision nearly always comes from the manufacturer.

Here’s what Active Data Foundations look like when done right.

In this short video, we walk through the discovery of a full VMware vCenter environment using a platform-native method. The entire process—from scan initiation to populated dependency map—completes in under 30 seconds.

The important part isn’t the tool—it’s the outcome:

• 98 configuration items

• 139 relationships

• Automatically mapped across ESX servers, virtual machines, ports, and data stores

That’s what it looks like when the platform speaks its own schema fluently.
And that’s what Suggestion needs if it’s ever going to act with confidence.

The real requirements for JIT data are connectivity and contextual depth. In the MAC address example above, the platform needs an integration to the wireless controller—and a way to perform a live lookup that returns the location of the access point currently serving that MAC address.

That same wireless controller may also emit a live event stream about the health and status of its access points. And critically, that’s a completely different integration. One handles on-demand lookup. The other handles streaming events. We should also add to that a third integration—one that likely ran earlier—advising the platform of the existence of the AP and the controller, and how they work together.

As AI platforms grow, they must support the full range of native integrations:

• Data Foundation population

• JIT real-time lookups

• JIT event streams

Without all three, Enterprise AI will remain brittle—asking the right questions, but unable to provide the correct answers.

Foundational Capability 3: Enterprise Trust (Preview)

Most efforts today focus on the first two Foundational Data Capabilities: How do we give an AI access to all the data it requires to perform?

But this third capability—Enterprise Trust—still isn’t getting the attention it deserves. This layer governs what the AI believes—and why.

• It determines source reliability, conflict resolution, and authorization signals

• It spans both static content (docs, policies) and dynamic inputs (user assertions, logs)

• It includes version control, recency weighting, privilege context, and even intent inference

Enterprise Trust is the AI equivalent of chain of command. Without it, Suggestion is just noise.

No matter how complete our data, there will always be conflicts. Static sources will lag behind real-time signals. Documentation will differ from logs. And even when both align—what happens when I, the operator, say:

“I know you’re supposed to shut it down at 85%, but today… let it go to 90.”

Am I a trusted engineer who knows exactly what I’m doing?

Or am I a threat actor?

And how does the AI decide?

That’s the final gate between Suggestion and Execution.

We’ll be expanding on this in the future—because it’s that important. But it also belongs here, in outline form.

Because if you don’t solve for trust, no matter how good your data is, your agents will never be able to use it correctly.

Conclusion

Everyone wants agents that can act. But the truth is—most enterprises are not yet ready for autonomous execution.
They’re still trying to answer a more fundamental question: How do we help AI suggest well enough to act at all?

The DREAM model makes this gap visible.
Execution only works when Suggestion is reliable. And Suggestion only works when grounded in:

• Structured source data

• Refreshed, real-time context

• A working system of trust

These are not abstract ideals. They’re buildable layers—capabilities that can be strengthened.

The first two—Source Data Control and Active Data Control—are already receiving investment.

The third— Enterprise Trust—is only beginning to be understood. But it may prove to be the most important of all.

Because if we want AI to move forward with confidence, we must first ensure it knows what to believe—and why.

That’s the real work before the agent acts.

This post accompanies the official v1.0 release of the DREAM framework. Future revisions will be tracked here and in the PDF download.

Download Before the Agent Acts v1.0: Building the Foundation for Autonomous Execution PDF - Part of the Deitsch’s DREAM Enablement Series (Design Reference for Enterprise AI Maturity)

Around here, however, we don't look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious...and curiosity keeps leading us down new paths. - Walt Disney (attributed)

By David Deitsch
Technology Workflows Architect | AI Strategist

Executive Summary

While AI is no longer theoretical, many organizations are still struggling to realize its full value. The technology is available, but the outcomes often fall short—not because of a lack of access, but because of how the work is structured. Too many teams rush toward automation without recognizing the most critical middle layer: reliable suggestion. In many cases, they aren’t even aware they’re skipping it. The absence of structured suggestion is invisible—until execution fails or trust breaks down. Most enterprise AI adoption to date has focused narrowly on conversation—summarization, rewriting, and retrieval—repeated across a surprisingly limited set of use cases. That’s only one-third of the model. Until organizations begin to treat suggestion and execution as distinct areas of design, they’ll continue building shallow wins on top of untapped potential. This white paper introduces Deitsch's DREAM (Design Reference for Enterprise AI Maturity), a framework that re-centers the conversation around how real organizations—today—should build AI systems that scale. It also presents three design principles that help organizations move beyond conversation: how to architect AI for reusability, and how to rethink where workflows need to begin.

Defining the DREAM Model

Conversation → Suggestion → Execution

We’ve entered a golden age of conversational AI, thanks to foundational models like GPT-4. GPT-4 and other leading large language models (LLMs) didn’t just improve conversational AI—they completed its first major milestone. For the first time, enterprise users could engage in natural dialogue with a system that understands nuance, context, tone, and intent. That leap is what made this model possible: it showed us what happens when a stage reaches maturity. But suggestion—the ability to interpret complex input and consistently propose actionable next steps—is where most AI efforts stall. Without rock-solid suggestion, execution isn’t just risky—it’s largely out of reach. The kinds of autonomous changes leaders often imagine, like automatically deactivating users in a production identity system, remain years away for most organizations. The systems aren’t ready—and neither is the trust. This model reframes AI maturity in three stages:

- Conversation: Natural language interaction and context awareness

- Suggestion: Reliable, repeatable recommendations

- Execution: Delegation of tasks with confidence

Until suggestion becomes enterprise-grade, execution at scale remains out of reach—not just technically, but operationally. The trust isn’t there. The architecture isn’t there. The leap too many are imagining still depends on a bridge that hasn’t been built.

Three Design Principles for Enterprise AI Value

A Note on Gartner’s AI Maturity Model

The Gartner AI Maturity Model is widely used to assess where organizations stand in their adoption journey—from awareness to operationalization. Deitsch's DREAM doesn’t compete with that—it complements it. If Gartner’s model tells you where you are, Deitsch’s DREAM framework tells you if you’re moving. And more importantly, how to stop wasting time if you’re not.

The ideal end state of AI execution sounds magical: tell the system what you want, and it figures out the rest. It knows what information you need. It understands how to get it. It gains access, takes action, and reports back. When that day arrives, architecture may not even be visible—it will just work. But we’re not there yet. And until we are, what matters is how we architect using the tools we have. The model ends there—but the work doesn’t. To make AI maturity actionable, we need principles to guide how we build. The next section introduces three design principles that help organizations move from theory to architecture—and from potential to value:

Principle 1: Granularity

Granularity is the design bridge between suggestion and execution. Any time the AI system cannot be trusted to decide what comes next, a new boundary must be introduced. Pause the flow. Reset context. Start a new agent.

This approach doesn’t slow us down—it keeps us aligned with how enterprise trust is earned. Execution can’t leap over uncertainty. Granular architecture identifies that uncertainty—and builds a safe handoff around it.

Example: Active Directory Permission Request

Imagine an operator asks the AI to grant a user specific permissions in Active Directory. In a naive design, the AI might propose a method—and immediately execute it.

If that workflow isn’t reliable, we need to locate a Granularity Inflection Point.

That’s where we insert a checkpoint: after Suggestion, before Execution. This pause allows a human to review, confirm, or override the action. Suggestion and Execution are no longer fused.

And here’s where granularity gives us even more power:

If we know the AI struggles to make the right suggestion, we don’t throw out the workflow—we move the trust boundary earlier. We guide the AI with scripts, templates, or curated tools. That way, even if it can’t improvise yet, it can still suggest the right method—every time.

Granularity doesn’t just protect execution. It defines how we scale AI while trust is still catching up.

Principle 2: Reusability

If granularity helps us manage trust, reusability helps us scale.

The more often a task appears across workflows, the more valuable it becomes to isolate that task into its own agent. To increase reusability, broaden the applicability, shorten the scope, and reduce required inputs. A reusable agent does one thing well—and does it often.

Consider this example: an operator asks, “Where is the device with MAC address 48:e1:5c:ad:3d:a2?”

The task is routed through a series of agents. One of them takes a network device name (like dave_ofc_sw11) and converts it into a human-readable location (like “David’s House”).

That’s reusability in action.

The second agent, the one that maps network gear to physical location isn’t specific to MAC addresses—it’s a small, focused task that adds value across dozens of use cases. That’s what makes it reusable: it’s not designed around the task that triggered it, but around the value it can provide to others.

Reusability isn’t a bonus—it’s a design objective. The more reusable components we create, the faster future architectures will come together. Reusability is how we escape one-off thinking and build toward orchestration at scale.

For a full walk-through of this MAC address orchestration flow, visit:

Principle 3: Applicability

Most enterprise workflows begin where the system expects structured input. But what if that’s not where the real work begins?

Conversational AI excels at interpreting messy, incomplete, or misformatted requests. That’s not a limitation—it’s an opportunity. In the MAC address use case, AI doesn’t just help answer the question; it helps reinterpret how the question is asked. A user might enter an address in the wrong format or not understand what they’re even looking for. Traditional systems would reject the input. A language model adapts. It recognizes the intent, corrects the format, and makes the workflow viable.

That’s what makes applicability so important. The more we rethink where workflows begin, the more value we can unlock from AI’s strongest capabilities. If conversation is where AI is already mature, we should move our problems closer to it—not ask AI to stretch into areas where it isn’t ready. That’s how we uncover value we’ve been stepping over.

Proving the Model: A Week Inside the System

In just one week, the framework wasn’t just produced—it was demonstrated. In just a few days, Deitsch's DREAM framework was developed, tested, and refined through sustained interaction with GPT-4. The speed wasn’t the story—it was how the work happened. The process was not about automation, but collaboration. Not about outsourcing thought but accelerating it.

When AI supports communication—its clearest strength—its suggestions are accepted with fluency and confidence. Iteration shrinks. Convergence accelerates. What emerges isn’t just text—it’s aligned thought. Structured, resonant, and faster than either party could achieve alone.

Contrast that with AI applied to tasks like scripting, debugging, or configuration. There, the dynamic shifts. Testing, troubleshooting, and trial-and-error dominate. Suggestion falters. Execution, without mature suggestion, slows to a crawl.

That contrast is the real insight. This paper came together so quickly because the process stayed inside AI’s current zone of strength: high-quality suggestion in a domain where suggestion is enough. This wasn’t automation. It was augmentation. GPT-4 didn’t create this model. I did. But I created it through the system—not by chance, but by design.

Looking back through this paper, none of the original thought came from AI. Every core idea—Conversation, Suggestion, Execution; and the principles of Granularity, Reusability, and Applicability—originated with me. What ChatGPT gave me was acceleration: the ability, through conversation, to clarify, structure, and express those ideas in hours, not weeks. That’s the shift. And it’s why the work speaks louder than the timeline.

Origin Story: The Confidence to Publish

This framework didn’t come from a workshop, a lab, or a directive. The catalyst came in January, when ServiceNow expanded its Pro Plus offerings and brought domain-specific generative AI to real workflows across the platform—from ITSM to HRSD to App Engine. That signaled the shift from theory to application. In my role, that shift wasn’t abstract—it was personal. I had to make the technology real for customers. So, I started building a language in my head, to explain what I was just beginning to understand.

But I never expected to express it clearly—let alone publish it. What changed? I did the work, with help. Each of my sessions, with all types of LLMs, weren’t just for productivity. They became part of a wider creative process: a consumer dispute, a book in progress, a public-facing brand. Those weren’t distractions—they were reps. They provided clarity and momentum to return to my own domain and publish something that would speak directly to my peers. Something that could carry my name.

For these activities—using ChatGPT—the LLM didn’t give me permission or create new thoughts. It gave me rhythm, structure, and a mirror. It helped me test, refine, and validate every line. That kind of back-and-forth is something even the best colleagues don’t always have time to offer. And without it, this paper probably wouldn’t exist.

Still, I recognize that I’m placing a great deal of trust in an AI system. And somehow, my willingness to do so coincides with the moment I knew the framework was real. Not because a system told me so, but because I could finally explain it to someone else. Cleanly. Clearly. On my own terms. And with signal strong enough to stand on its own.

That was enough to stop waiting. Enough to publish. Enough to know this wasn’t just any old idea—this was the one I needed to share.

This post accompanies the official v1.0 release of the DREAM framework. Future revisions will be tracked here and in the PDF download.

Download Deitsch's DREAM v1.0 - Design Reference for Enterprise AI Maturity PDF

Around here, however, we don't look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious...and curiosity keeps leading us down new paths. - Walt Disney (attributed)

📽️ Demo Video

Watch the clip below. This is what execution looks like—real work, done by AI.

Key Highlights

• Agents trace a MAC address across systems

• Executes real logic across ITOM, ITAM, and CMDB

• No manual steps—entirely automated

• Based on real ServiceNow architecture

Why This Matters

Everyone talks about generative AI—copilots, summarization, suggestions.

But this isn’t a suggestion.
This is an agent doing the work.
Planned. Bounded. Architected.

This was the moment AI crossed into execution—or at least, that’s how it felt at the time. In hindsight, it wasn’t quite the warp threshold I’d later come to recognize. That came weeks later, during a different experiment with GPT-4o—one that built, tested, and debugged a document automation system almost entirely on its own.

Still, this moment mattered. It revealed something important:
We can argue endlessly about what is or isn’t “real” AI.
But the deeper point is simpler—did it produce a real outcome?
Because in the end, that’s all anyone is really looking for.

And to borrow a thought from Arthur C. Clarke:
“Any sufficiently advanced technology is indistinguishable from magic.”
Because at some point, when the results speak for themselves, it matters less whether it was AI or not. What matters is that it worked.

What’s Next

This demo is powered by a larger framework:
Deitsch’s DREAM – Design Reference for Enterprise AI Maturity.

That full framework drops soon. It’s the architectural blueprint behind agentic execution in the enterprise—governing, scaling, and grounding these agents with clarity.

Around here, however, we don't look backwards for very long. We keep moving forward, opening up new doors and doing new things, because we're curious...and curiosity keeps leading us down new paths. - Walt Disney (attributed)