Agentic AI Systems Are Not Technology

Preface

Like its predecessor, “Thinking is a Process”, this paper aims to make invisible patterns visible. “Thinking is a Process” showed that thinking isn’t mysterious–it follows structured, repeatable patterns (decomposition, option generation, evaluation, iteration). Making those patterns explicit enables deliberate improvement. We make the case here that agentic AI systems aren’t just “advanced software”; they transcend the technology category and require new mental models and organizational frameworks. Making this category distinction enables better systems design, management, governance, and security.

The pattern: When mental models are implicit, confusion follows. (Agents don’t behave like technology, but we treat them as such). When mental models are explicit, clarity is possible. (Agents are autonomous cognitive systems; now management strategies can make sense). Clarity enables action.

A Note on Scope This paper focuses on agentic AI systems that use stochastic and heuristic processes to create plans, make decisions, coordinate resources, and execute work. We submit that this combination of elements distinguishes agentic AI systems from previous technology systems, including generative AI.

Part 1 The Broken Triad

The People-Process-Technology framework is a familiar triad. If you’ve worked in technology, consulted for organizations, or managed any form of digital transformation, you’ve encountered this framework. Management consultants use it to structure engagements. Technology executives use it to diagnose systems dysfunction. Strategy decks cite it to allocate budgets across three dimensions. The framework is simple, almost obvious:

• People : The humans in your organization–their skills, motivation, culture, training, collaboration patterns, and decision-making capacity.
• Process : The workflows, procedures, policies, and governance mechanisms that coordinate work– how things get done, who approves what, which steps happen in which order.
• Technology : The software, hardware, databases, networks, APIs, and infrastructure that enable and automate work–the tools people use to execute processes.

The elegance of this framework lies in its clean boundaries. People are not processes. Processes are not technology. Technology is not people. Each category has distinct characteristics, distinct management strategies, and distinct failure modes.

Example: A Sales Organization

• People : Sales reps with relationship skills, motivation to hit quota, cultural norms around collaboration vs competition.
• Process : Lead qualification workflow, approval chains for discounts, forecasting procedures, compensation structure.
• Technology : CRM system (Salesforce), email automation, analytics dashboards, Zoom for demos.

Problems? If sales performance drops, the framework guides diagnosis:

• People problem? Skill gaps (need training), motivation issues (fix incentives), cultural dysfunction (address conflict).
• Process problem? Workflow bottlenecks (streamline approvals), unclear responsibility (define RACI).
• Technology problem? System downtime (improve reliability), poor usability (redesign UI), missing capabilities (integrate new tools), data issues (improve data ingestion, add data QA processes)

The framework works because the categories are mutually exclusive and collectively exhaustive (MECE, in consultant-speak). Every organizational capability maps cleanly to one of the three. Every problem traces to a deficit in one or more categories.

A Brief History of the Triad

The People-Process-Technology framework emerged during the business process reengineering movement of the 1990s. Michael Hammer and James Champy’s 1993 book, “Reengineering the Corporation”, popularized the idea that organizations could achieve dramatic performance improvements by fundamentally redesigning workflows – not just by hiring better people or buying better technology. The insight was radical at the time: Process matters. Organizations had spent the 1980s investing heavily in technology (PCs, databases, early enterprise software) but often saw disappointing returns. Why? Because they had automated broken processes. The technology worked fine. The people were competent. But the underlying workflows were inefficient, redundant, or misaligned with business goals. Process reengineering became the corrective: First fix the process, then apply technology to amplify the improved workflow. And ensure people have the skills and culture to execute the new process.

The three-way categorization stuck because it clarified responsibility:

• Department Managers and HR manage People (hiring, training, culture, motivation).
• Operations and Strategy manage Process (workflow design, governance, continuous improvement).
• IT and Engineering own Technology (infrastructure, tools, systems, integration).

This division of responsibility enabled specialization. Each function could develop deep expertise in its domain. Problems could be triaged efficiently: “This is a people issue → escalate to Management or HR.” “This is a process ga → Operations needs to redesign the workflow.” “This is a technology failure → IT will patch the system.”

For three decades, this framework has been the default mental model for understanding organizational capability. It appears in:

• Consulting frameworks: McKinsey, BCG, and Deloitte all use variations of the triad.
• Academic research: Organizational design, change management, and digital transformation literature cite it extensively.
• Corporate strategy: Annual planning processes allocate budgets across people (headcount), process (operational efficiency programs), and technology (IT spend).
• Regulatory compliance: Standards like ISO 9001 (quality management) and SOC2 (security) organize controls around people, process, and technology.

The framework’s longevity suggests it captures something fundamental about how organizations work. But does it still hold?

The Problem: Where Do Agentic AI Systems Fit?

Enter agents. By agents, I mean autonomous AI systems that reason, plan, make decisions, and execute tasks, sometimes with minimal or no human supervision. These systems are no longer hypothetical. They exist. They work. And they create an immediate classification problem.

Initial instinct: agents are technology. After all, agents run on computers. They’re software. They use APIs, databases, and infrastructure. They’re built by engineers. They’re deployed via code releases. By those measures they look like sophisticated software systems.

First tension: Agents exhibit emergent and divergent behaviors in ways and to degrees that we would normally associate with human beings. When you interact with an agent, it doesn’t feel like using software. It feels like collaborating with a colleague. This is not input → deterministic output’ (like querying a database). This is conversation and heuristic reasoning. The agent is asking clarifying questions, inferring unstated context, and adapting its approach based on your responses. Does that sound like technology? Or does it sound more like a person?

Second tension: Agents design processes and create new technology. When you delegate work to an agent, it is capable of thinking about the intended goal and then designing its own workflow. The agent isn’t just a tool used in a process. It is often the designer and owner of the process. Agents can create new technology. They can (and often do) write scripts and apps to achieve their goals. And they can do this without the user explicitly asking them to do that. These are capabilities that we normally would associate with people, not technology.

Third tension: Agents don’t behave like traditional technology. Here’s where the confusion deepens. If agents are technology, they should behave like technology. But they don’t.

• Technology is by-and-large predictable: Run the same database query with the same underlying data, get the same result. Agents are stochastic: Ask the same question, get different answers. This behavior is the result of design. It is not a bug. If you try to remove the stochastic behavior from an AI model, it becomes incapable of advanced reasoning.
• Technology systems have finite and bounded capabilities: A CRM system tracks customers–it can’t suddenly do financial modeling. Agents have the capacity for unbounded reasoning: An agent can shift from marketing strategy to debugging code to philosophical discussion within the same conversation.
• Technology is quasi-static: Software doesn’t improve itself; engineers release updates. Agents evolve and accumulate experiential memory: They learn your preferences, build mental models of your organization, refine their heuristics through interaction.
• Agents are opaque: Much of their reasoning is distributed across neural network activations – there is no single ”state” to inspect. And if you are using a closed AI model, these neural networks are not available for inspection.
• Agent reasoning is difficult to trace and diagnose: If you do have full observability into your agent’s reasoning model, that does not mean you have the effective ability to diagnose and correct an undesired behavior. Iterative trials or empirical experiments are often the most effective and efficient ways to generate the behaviors you want.
• By and large, you cannot apply typical regression testing methodologies to agents. There are many reasons for this, but the easiest to understand is that it is usually difficult to impossible to define a compressed assertion rule that will provide a binary pass-fail result to a regression test.

If agents violate these characteristics that define “technology,” are they technology? We propose that defining agentic AI systems as technology is a category error – like trying to classify a whale as a fish because it lives in water. Superficial similarity (both swim) masks fundamental difference (whales are mammals, not fish). Agents run on computers (superficially “technology”) but have characteristics fundamentally incompatible with how we define and manage technology, particularly within the people-process-technology rubric.

To further our point, consider this thought experiment: Imagine you’re managing an organization with both traditional technology and agents. You have a CRM system (traditional technology) and an AI agent.

The CRM system:

• Predictably stores and retrieves customer data.
• Has finite, enumerable states (records exist or don’t; fields are populated or empty).
• Does exactly what it’s programmed to do (track customers, nothing more). – Changes only when engineers release updates.
• State is fully inspectable (run queries, see exactly what’s stored).

The Agentic AI System:

• Adapts recommendations based on conversation context, recent events, and inferred priorities.
• Has uncountable mental states (after 10 conversations, the agent has built a rich mental model of the problem at hand and we can not practically enumerate all possible states).
• Reasons about anything you ask with unbounded capability (operations, strategy, hiring, technology architecture).
• Continuously improves (learns your communication style, refines operational heuristics, gets better at prioritization without a new release).
• Internal reasoning is highly opaque (You can’t inspect the current mental state and trace back the state transitions over time. It is unlike querying a database).

Question: Are these both ”technology”? If your answer is “yes, but agents are just more complex,” ask yourself: At what point does quantitative complexity become a qualitative difference? At what point does a system produce emergent characteristics that distinguish its nature of being from that of its individual elements?

The Stakes: Why This Matters

This is not academic hair-splitting. Your mental model shapes your decisions. If you categorize agents as “technology,” you will manage them like technology:

• Deploy and monitor : Treat agents like services (check uptime, error rates, performance SLAs).
• Configure and control : Manage via access permissions, rate limits, sandboxing.
• Test deterministically : Write regression test suites with expected outputs.
• Upgrade via versioning: Release version 1.2 when capabilities improve, if there are problems roll back to version 1.1.

This approach will fail because the agentic system does not behave like what we expect from technology. You’ll be frustrated by:

• Non-determinism : Same input, different output (no stable test suite).
• Emergent behavior : Agent does something unexpected but contextually reasonable and effective (not a “bug”, but surprising).
• Divergent behavior: When the agent approaches its cognitive limits, it begins to “poison” its context. This problem is rooted in the same underlying issues that produce “hallucinations”, but context poisoning need not be as obvious as stating a false fact. It can involve gradual loss of precision and direction in the context. After enough turns, the agent can “lose its way” and begin pursuing goals and actions that are outside of the scope of what you desire.
• Continuous evolution: Agent’s behavior changes without a “release”. The cause-effect relationship for agent behavior is largely influenced by what is contained in the agent’s long-term memory system. That memory is updated continuously as the agent runs. And behavioral changes usually cannot be traced back to any single change to memory. Put simply, there is usually no known stable version to which you can roll back.

Are AI Agents People?

Many people recoil at the suggestion that you categorize AI agents as people. That reaction by itself is not a sufficient reason to avoid analysis of the comparison. Instead, we make the rational case that categorizing agents as people is incorrect.

Let’s walk through the case where we categorize AI agents as people.

• Hire and train : Onboard agents, teach them company context, define their role, and educate them on policies.
• Alignment : Provide clear goals and feedback when outcomes diverge from the desired path.

We can do those two things with agents. And the way we think about doing those things can be remarkably similar to the way we would do the same things with a person.

There are other ways that agents are like people:

• Cognitive overload : put too much information into an agent’s context and its performance will degrade. Just like every person has a limit to how many things they can hold in their momentary context.
• Forgetfulness : just like humans, agents have short-term memory (momentary context) and long-term memory. If a long-term directive fails to make its way from short-term to long-term memory, it is forgotten. Even when the right information is in the agent’s long-term memory, that is no guarantee that the agent will find it and load it into momentary context when that memory is needed. We do not expect people to have perfect memory recall. The same is true for AI agents.
• Ambiguity : from the perspective of reasoning behavior, agents are remarkably like people when it comes to information ambiguity. Just like people, agents will try to fill in the “missing pieces” using logic and heuristics. Sometimes they do that well and sometimes not. Just like people. From a management perspective, the solution is the same – make directions and explanations as complete and unambiguous as possible.

Here is where the analogy breaks down:

• Accountability : You cannot motivate an agent using the same reward-punishment rubric that you would use with a person.
• Relationships : Humans form trusting relationships with each other over time. These relationships then form networks of trust. For multiple reasons (e.g. human affinity for other humans, personal motivation, ability to keep personal secrets) we think we are far away from the day when AI agents will be capable of participating as peers in human trust networks.
• Scalability : Have you ever wished you could clone an employee or work colleague, because they were better at their job than anyone else? You can’t do that with people, but you can with agents.
• No Fatigue: Agents can work 24/7 without any change in their effectiveness.
• Emotionality : Agents lack human emotion. This means they never get upset, frustrated or otherwise demotivated in ways that affect their ability to do their work.
• Vulnerability : Agents are vulnerable to things that humans are not (at least not in the same ways). Delete the wrong part of an agent’s memory and it will fail. Agents can be maliciously “jail broken” in ways that are similar to SQL injection attacks. This can also happen by accident when a person or other agent injects bad information into context or long-term agentic memory.

Are AI Agents Processes?

If you categorize AI agents as “processes,” you’ll document and standardize them:

• Write process documentation : “Here’s how the agent works.”
• Enforce governance : Require approvals, audit trails, compliance checks.
• Standardize outputs: Define templates, formats, quality criteria.

This approach captures part of the truth (agents execute processes) but misses that agents are self-executing and capable of adaptive behavior when proscriptive processes would otherwise fail. Agents are dynamic, adaptive systems that can design processes and improve them autonomously through feedback. Agents are self-executing – they can design a process in one step and begin executing it in the next step.

Conclusion

Agents don’t fit cleanly into any of the three categories. They are not people. They are not processes. They’re not technology. So what are they?

We propose that agents transcend the “Technology” category and are a new category: Autonomous Cognitive Systems.

We support this conclusion using the following 5-step process:

Step 1 : We ask what makes technology “technology”? We define five characteristics that distinguish technology systems: determinism, state machines, bounded operations, static behavior, and inspectable state. These characteristics enable reliability engineering design, deterministic testing, monitoring, and control. These aren’t arbitrary; they’re the foundation of how we architect, design, build, deploy, and manage technology at scale.

Step 2 : We examine each characteristic in turn and demonstrate that agents don’t just stretch the definition of technology, they violate every characteristic systematically. Agents exhibit stochastic heuristic thinking (not deterministic Boolean logic), contextual memory (not state-based), unbounded reasoning (not constrained), continuous evolution (not static), and semi-opaque processes (not effectively traceable).

Step 3: We propose what agents are. If agents aren’t technology, what are they? from simple to complex software. We propose that agents are Autonomous Cognitive Systems – a genuinely new category that combines cognitive capacity (reasoning, like people), autonomy (self-executing, unlike processes), and adaptability (continuously learning, unlike technology).

Step 4: We examine the implications for organizations. If agents aren’t technology, how should we manage them? We explore practical implications for management and how recognizing agents as a distinct category changes management (behavioral evaluation, not monitoring), governance (normative standards, not access control), organizational design (peer collaboration, not tool usage), investment (capability development), change management (behavioral evolution, not system upgrades), and accountability (judgment evaluation, not fault finding).

Step 5: We reconceptualize the People-Process-Technology framework. We propose a new organizational model: Normative-Cognitive-Technological layers that replace People-Process-Technology. This framework accommodates agents: it clarifies their role in organizational architecture and how to integrate them into organizational design.

In Part II of this series, we will dive deeper into why AI agents are a distinct category from technology. We do this not just to further the case that they are distinct, but also to examine the key differences that may provide insights into how we manage AI agents.