Other types of AI Strategies include: 1) industry level strategy, 2) targeted or product-level strategy or 3) Transformation-specific strategy - for large initiatives which thus exists somewhere between enterprise and targeted scope.

Where Did (most) Data Strategy Go Wrong?

What went wrong with the premise of the Data Strategy and what does that have to do with an AI Strategy anyway? Well, let’s start with a conceptual comparison first; both Data and AI are thoroughly ubiquitous within an organization’s IT ecosystem. If something is in everything and it’s found everywhere; how do you classify let alone deal with it? There may have been what I believe to be a misconception at the start of the Data Strategy trend that this construct (and any associated initiatives or roles) could limit itself entirely to the field of Data Management. But that was only half true and we likely knew that at the time when this bandwagon got rolling (in the 2000’s). The parallel with today of course is that many still think of AI as being associated with specific AI products such as OpenAI’s ChatGPT and Anthropic’s Claude so managing those could be viewed as an “application niche.” While the introduction of several chatbots may have been a valid way to view things in 2024, it certainly isn’t anymore (even if the same foundation models rest at the heart of all of the other products springing up or integrations with existing software).

In other words, as much as we’d like to view specific technologies as well-defined domains, they sometimes instead represent cross-cutting capabilities that end up reaching into every corner of the typical enterprise. When that happens, the strategies targeted towards dealing with those capabilities can and do go off the rails. But while the scope issue was the starting point for what happened with Data Strategy, it wasn’t the only one; other problems included:

• As noted, the scope did not take into account the true cross-cutting nature of data which in turn handicapped later efforts to implement Data Governance and to understand how data ought to be managed in the context of various types of transformations. To be better understand this, let’s look at Data Warehouses (or Lakes, etc.). These aggregate data structures typically brought in data from elsewhere but also enhanced it, creating what essentially was new data - governing and managing data along its value chain became very complex and ended up resulting in conflicting answers from what seemed to be on the surface anyway, the same data.

• Far too many instances of generic language (in the strategy itself). While these strategies were quite popular well before the advent of LLMs, it certainly seemed as though many if not most of them were written by GenAI. That’s because far too often the content was not specific to the organizations using them and thus could be easily copied / pasted and still earn a “mission accomplished” button. As you might have guessed though, a generic Strategy (of any sort) is next to worthless in the real world.

• It often led to artificial divisions of labor. There were times that a strict interpretation of how Data Management should operate led to islands of data capability being managed by different groups (typically split across business and IT) that ended up more or less defeating the purpose of both the Data Strategy and Data Management expectations.

• Lack of clearly defined Data roles and associated Business Processes. While there were explanations of what many roles should be responsible for and the basic context of workflows (through standards such as DMBOK and ITIL etc.), those were just starting points which too often were never extended to the last mile. And these roles sometimes hid the true nature of the full scope of work that the person holding them must perform; thus a role like “Data Steward” typically became a secondary role not associated with the true job description that the person held. The result of this was to assign duties that people might not have time to actually perform.

The question you might be asking now is; how much of this could have actually been specified in a strategy document? Well, that depends on how you interpret Strategy. Strategy can be considered perhaps to be incredibly vague guidance paired with associated principles or a concept of operations or alternatively it can be viewed as a Blueprint. If viewed as a Blueprint, an AI Strategy can be a meaningful next step after an Assessment and then provide the actionable foundation for follow-on planning, architecture and governance. And yes, a Strategy can be that blueprint.

But can a Strategy predict the future well enough to serve an organization as it moves into an uncertain future? Or does it really need to predict the future to cope with AI?

Prediction is Tricky, Extension not so much…

It’s worth stepping back for a moment and talk about Strategy versus Prediction. There are some who may think that in order to have an effective Strategy (of any kind), that you need to be good at predicting innovation, markets, combined trends and so forth. The reality is of course that prediction is hard and typically not very accurate beyond a certain window or threshold. The maximum window or threshold tends to be around 5 years, but that duration doesn’t hold for everything - it applies only to those areas that historically have moved slowest. For faster moving trends and this includes technology innovation, a more realistic threshold is likely about 3 years. And think for a moment where we were just 3 years ago in relation to AI (and LLMs in particular); early that year ChatGPT went from 100 million to 1.7 billion users in just a few months and more or less disrupted most notions about what AI might (eventually) be able to do in the workplace. That type of disruption would have been impossible for most to guess five years prior and even 3 years before (in 2020) it seemed perhaps unlikely; although it’s worth noting that in the case of GPTs, expectations have run well ahead of capability delivery too - so even with AI - 3 years might be a reasonable window to work with.

So, if we can’t make accurate predictions very far out in advance with great certainty (at least consistently), how do we go about making an effective strategy? Here’s a set of guiding principles that have helped me across the past few decades when faced with this type of tasks:

1. Understand the problem space; this means you must know your history at both the industry and organizational level. It also means that understanding the business of the client (as well as the associated IT environment) is just as important as understanding specific tech products or new tech.

2. Don’t make assumptions based upon either that history or the hype coming in relation to those new technologies that may disrupt that industry or organization.

3. Be able to identify the key issues unique to that organization and address those appropriately in the Strategy; don’t get too bogged down in the detail, though.

4. Remind yourself that even in the most aggressive transformations, an organization never really reinvents itself, it merely extends or shifts its capabilities in a manner most likely to assure continued success in a changing environment. This realization often directly contradicts the hype associated with new tech such as AI, but this is always the case and that hype is invariably wrong - at least when viewed in 3-5 year windows - which is the only duration that matters to a Strategy (BTW - a ten-year strategy is not an actionable document, it’s a vision statement).

5. A strategy can and should take into account that at least some of the expectations associated with its 3-5 window in which it will be valid, may diverge from what is happening in the real world. Thus the strategy can and should be flexible enough to deal with that (e.g. it doesn’t actually have to be infallible).

So, What Should an AI Strategy Look Like?

Each one has to be specific and unique to add real value to the organization in question; however, there are certain general principles which ought to be applied to an AI Strategy including the following;

• It should address both AI-related risks and opportunities (and these might be identified in previous Assessments, but if not, some effort must be made to identify them here in the strategy).

• It should include a clearly defined duration and scope (as noted above).

• It should clearly define enterprise goals and objectives while also highlighting expectations for mission continuity.

• It should be tailored to both the unique mission, business and culture of an organization while simultaneously keeping in mind associated industry expectations and trends.

• It should include at least some metrics that can then be assigned to follow-on plans, programs and projects (and it ought to also identify at some of what those programs ought to consist of).

What About AI-Specific Considerations?

This is an AI Strategy after all, right? So, what types of things should we be including in the middle of 2026 to help prepare an organization to deal with at least the next several years of AI exploitation? Here are some thoughts:

1. The AI Strategy ought to include both an As-Is and To-Be review of AI expectations within the organization. This may sound redundant until we consider that expectation management is in fact one of the key benefit of having a strategy. It’s also a great way of helping to get past marketing hype and into real-world discussions.

2. It should also cover guidance in relation to suggested / recommendations programs or projects and as such should thus include a Roadmap which illustrates all of these, (and that guidance can be both internal and external in nature).

3. It should also reference any prior assessments that were used to help build the Strategy (and this would include things like an AI Inventory).

4. As noted, it should provide one or more ways to measure success or adherence to the Strategy. The most common metrics for AI-related capabilities will likely be cost efficiencies, new business attained and SLA performance enhancements (so maybe not that different from most other technologies after all).

5. It should be able to differentiate custom-built AI-related capability from COTS-adopted AI tools and then explain how any custom development will be folded into the existing DevOps paradigm.

6. It should address AI-related workforce impacts and include mitigations for them. In many cases, this might include knowledge capture efforts for any outgoing resources.

7. It should also clearly identified (near-term) business trends or shifts that are likely to occur to both as a result of the organization’s adoption of AI as well as associated market trends (and explain how the strategy accounts for those). This is the one area most associated perhaps with Prediction, but in reality it won’t be anything that most other organizations in the respective field are already discussing (and possibly have been discussing for many years). Most of the “Predictions” will in fact surround resolution of long-standing challenges as opposed to the introduction of new ways of doing business.

8. It should address quality issues and expectations associated with AI-produced services, (both internally used and externally provided). The reason why is that in the near-term anyway, quality issues will be the number one challenge associated with many AI-related endeavors.

9. The AI Strategy should also include AI security and data impact statements.

10. Lastly, the AI Strategy ought to include value propositions and ROI expectations associated with specific recommendations. For example, if the goal is to replace one or more BPM tools with an Agentic framework, the relative costs and benefits ought to be highlighted.

And of course as alluded several times already, Enterprise Integration (cross-cutting impacts) will be the most complex issue that most organizations will face in relation to AI adoption. The Enterprise AI Strategy must therefore maintain a holistic perspective and anticipate as many of those direct and indirect impacts as possible.

Copyright 2026, Digital Perspectives

Bad Data, AI’s official definition - Bad data refers to information that is inaccurate, incomplete, inconsistent, outdated, or duplicated, rendering it unreliable for decision-making or analysis. It often originates from human errors like typos, faulty system integration, or poor data governance, directly leading to flawed AI models, revenue loss, and poor operational decisions. (Google Gemini definition lifted mainly from IBM)

The above definition is interesting - but it almost makes me picture HAL speaking to Dave in 2001, A Space Odyssey and complaining about how Human Error was to blame for all of the strange happenings on the Discovery as it was speeding to Jupiter. In the real world today and in relation to AI, a malfunctioning HAL seems to be the norm and what’s more - we’re not disconnecting him.

In everyday practice, we tend to view data quality issues rather pragmatically, which in turn could inspire a better definition of bad data.

Bad Data, real-world definition - Information, in the form of results or outputs that is inconsistent with solution expectations, (for how often and how much answers can deviate from the correct values) and that fails various validation and / or quality control or PKI measures on a regular basis (e.g. not just during DevOps release cycles, but also during follow-on operations). Bad Data is typically unusable for the tasks assigned to the solution (whether they are operational or analytical) without some type of formal remediation process. This type of data remediation process typically includes constant human oversight and validation as well as routine (manual) corrections. More often than not, these types of data errors are the result of system faults rather than human error and the unanticipated costs of correcting them usually represents a major burden for the organization in question.

Let me make this very clear; these types of situations have always existed and I’ve seen the results of this up close in many organizations. In fact, having these types of data remediation processes in place (with their associated additional resources) tend to become some of the biggest motivating factors for future Transformation projects (even if the current bad data situation happened to have resulted from a previous, failed Transformation project). But, even though these situations have existed and do exist outside of the context of AI, they have never actually been tolerated before. When encountering these scenarios before AI, organizations always did one of two things:

• They rolled back the faulty solution to the previous one that had better data quality, or…

• They maintained remediation processes until such time as a new solution or solution fixes could be rolled out (and typically those fixes would be wholly dedicated to correct the poor data quality).

In today’s environment however, some organizations are refusing to acknowledge that their decision to deploy LLM-based solutions are presenting them with systematically consistent bad data and have transferred the burden of dealing with that issue to the employees managing such systems. Why would this happen? Because of the massive mismatch in expectations in regards to what AI is supposed to be able to accomplish right now versus what it can actually do. A similar situation is playing out in relation to Vibe Coding, but that too quickly gets linked back to data quality issues because of the planning and design of the data (and any necessary integration) tends to be handed off to the AI coding tool rather than being thought through by developers and data experts (leading to obvious conflicts and problems).

The Hallmarks of Bad Data

So, we’ve talked about Bad Data in general terms and we haven’t linked it to Synthetic Data just yet, but we can begin doing that by diving into some of the specific characteristics associated with poor data quality; they include but are not limited to:

• Incorrect values in operational contexts (typically transactional systems, but not limited to those). here’s an interesting article addressing how multi-agent systems deal with it.

• Semantic mismatches - improper context. (here’s an article which highlights some aspects of this problem). This can impact any type of system context for an AI-based solution (not just those associated with text processing).

• Completely made-up (nonsense) responses. This type of quality issue doesn’t happen too much in non-AI systems and is often associated with what is referred to now as Hallucinations. Citing papers or facts that don’t actually exist is a commonly referenced type of error here.

• Time sensitive quality issues - the data is out of date. This type of problem is typically associated with complex integrations (or complex systems with many inputs that are processed at regular intervals).

• Redundant, duplicative or confusing results from similar data entities. This is often corrected in non-AI solutions using Master Data Management (MDM), but an AI solution that pulls in what are in effect Master Data Entities and has no way to reconcile them could easily get caught into this type of trap.

Here is a good article from a Data Catalog vendor that looks at quality issues from a holistic perspective: 9 Common Data Quality Problems and How to Fix Them. It’s worth noting when addressing things like Extract Transform and Load (ETL), that AI solutions are now able to bypass traditional ETL vendor solutions entirely and handle these types of tasks - the problem with that is though there is a much greater chance of the process/es not being properly documented understood or integrated into larger daily workflows.

Why Synthetic Data is Bad

Let’s start with a definition…

Synthetic data is information artificially generated by computer simulations or algorithms rather than real-world events. It mimics the statistical patterns, correlations, and structure of actual data, making it valuable for training AI models, testing software, and analyzing data while ensuring user privacy by eliminating direct links to real individuals.

Synthetic Data has been a around for awhile; (random) Data Generators are built right into data modeling tools. But what’s happening now with Synthetic Data is happening on a monumental scale. The problem stems from how Large Language Models are trained. As each model iterations grows larger (going from millions to now trillions of parameters); the amount of available data (that hasn’t already been utilized) has shrunk to the point where there simply isn’t much (or any) real world data left to train on. The answer to this problem has increasingly been the use of Synthetic Data for AI model training. It’s difficult to find reliable metrics for how much Synthetic Data is now being used, but even two years ago then number was fairly high: “it often makes up 20%–60% of data for instruction tuning and up to 80% for safety training.” In the abstract for that paper they also mention that “models will be trained on datasets roughly equal in size to the available stock of public human text data between 2026 and 2032, or slightly earlier if models are overtrained.” It seems as though we’ve probably already reached that milestone.

So, what’s wrong with this type of data? Well, there are the well-publicized problems such as LLM model collapse, which is defined as…

LLM Model Collapse is a degenerative process where generative AI models trained on AI-generated data—rather than human-generated data—gradually degrade in performance, losing diversity and producing nonsensical, repetitive, or inaccurate outputs over successive generations. It represents a "self-consuming loop" where models learn from their own errors.

I like to use the analogy here of dubbing videotapes - each iteration degrades the quality eventually making the copies more or less unusable. But there are more fundamental problems with the idea of using fake data to train AI models which ought to be addressed as well (and yes, I think that model collapse or reduced model usability is the likely outcome associated with all such problems); those problems include:

1. As in traditional testing / quality assurance scenarios, testing with randomly generated only gets you so far and sometimes it can lead to major system problems as it creates a limited perspective that misses many of the real-world scenarios that tend to arise (which in turn would lead to a lot of rework if the testing isn’t supplemented with real world data). This actually has come up a lot for me while working with classified systems where access to the real data is problematic or impossible in certain development environments (which aren’t certified to hold such data). The only way to deal with that it is to include a testing phase in the certified environment that works with the actual data.

2. In the context of AI, generating Synthetic Data based largely upon data coming out of existing LLM models, will certainly perpetuate existing data quality problems (whatever they may be). And we know that many such problems exist as the “real world” sources that these models were trained on include such dubious outlets as Reddit and Grok and perhaps worse. In other words, we know that much of the human-generated content / data was bad to begin with.

3. Fake Data cannot make these systems smarter or more accurate if they are essentially providing the models the exact same inputs that they’re already receiving (just scrambled a bit, but still the same). This may sound like an obvious conclusion, but it’s one that the proponents of using Synthetic Data for training never mention.

4. Bias - use of fake data is already causing higher levels of model bias to emerge as this is a direct manifestation of reusing bad human data with minimal or zero correction. Examples of AI bias include; “include hiring tools favoring men, facial recognition misidentifying people of color, and medical algorithms prioritizing white patients over sicker black patients.”

5. Perpetuation of false expectations associated with model performance. This problem is subtle, but perhaps the biggest one of all. As AI-based systems (whether they are Foundation Models or Multi-Agentic Systems) get better at mimicking human-produced outputs, there is a tendency to believe that the job is done and that these systems can be adopted with a level of trust associated with older systems that actually did provide high levels of data quality. The problem here of course is that the data quality issues with the AI systems are more profound and difficult to mitigate than ever before. For example - no one using these models can go in and fix data quality; we can only correct bad data coming out of an AI model ‘after the fact’ by building remediation solutions on top of the models and / or expecting employees to identify and fix it all manually.

What all of this points to is the realization that using our current training approaches, LLMs cannot be improved much if at all and in fact continuing to use these approaches may in fact make them worse. Now this conclusion has actually already played out in real life somewhat; the best example of this is with the rollout of ChatGPT 5 versus version 4. Many if not most GPT users thought that 4 performed better and the rollout was considered a disaster. The version 5 model was supposed to be superior in every respect, and was much larger in some respects; (GPT-5 expands the context window to approximately 272,000 tokens for input and 128,000 for output, offering a larger workspace than GPT-4o’s 128k limit). So why was it so underwhelming for users?

Reports suggest that OpenAI's GPT-5 (often referred to in 2025 as the latest generation model) has been trained on a massive dataset heavily augmented by synthetic data, with estimates ranging as high as 50 trillion synthetic tokens. This synthetic content, generated by preceding models like GPT-4 and o3, is designed to enhance reasoning and fill gaps where high-quality human-generated data is scarce.

There is no official data associated with the training process as OpenAI is not actually an Open model anymore. But indicators seem to point to a much higher reliance on fake data and OpenAI is not alone in this situation - every AI vendor is in the same boat.

And for end users, the organizations that that are or will become dependent on these systems, the situation is not looking good. Adoption of these solutions adds significant levels of risk (associated with poor quality) yet provides fewer ways to mitigate those risks. What’s the answer then? Will organizations even have an option to avoid using these technologies given that they’re being built into every other type of traditional software solution right now? It’s not clear. What is clear though is that the AI industry as a whole has taken a wrong turn down a dead end street and they’re dragging everyone else along with them. What needs to happen is a reevaluation of the system goals at a fundamental level - this would include for example something as simple as finding ways to build the solution around quality data from the ground up, as opposed to depending on garbage or fake data to magically make a solution intelligent. We’ve talked about how this might occur in other articles here on Digital Perspectives if you’re interested in that dialog. In the meantime, expect Data Quality problems to become more common as AI training dependence on Synthetic Data moves closer to the 100% mark.

Copyright 2026, Digital Perspectives

Anthropic’s Core Ethical “Red Lines” and Violations
Anthropic has drawn two major ethical “red lines” for their AI model, Claude, which they refuse to cross for the Department of Defense (DoD):

• Autonomous Lethal Warfare: Using AI for weapons that can make life-and-death targeting decisions without human oversight.

• Mass Surveillance of Americans: Using AI to assemble, analyze, and profile citizens’ movements and data on a large scale.

The story got even more complex when it was revealed that Anthropic’s tool/s were in fact being used to help both plan and execute parts of the recent US attacks on Iran. Also, as the dispute was building up between the company and the Government, Sam Altman - the CEO of OpenAI - stepped in saying that he would help to negotiate a settlement between Anthropic and the Trump Administration. Instead, within 24 hours of making that statement, Altman negotiated a new deal with the federal government for his own company (apparently forgetting entirely that Anthropic existed). Within a day of writing that federal contract for OpenAI though, Altman came out and said that the wording in it was opportunistic and sloppy and would be modified (see below). Why did he say that? Well, as soon as Anthropic stood up to the bullying of SecDef Hegseth and Trump and Altman made his side deal, users by the 10’s of thousands dropped their OpenAI subscriptions and downloaded Anthropic’s tools (ChatGPT uninstalls jumped by 295% in one day and 1 star ratings jumped by 775%).

According to Altman, the new contract language will state that OpenAI’s AI systems shall not be “intentionally used for domestic surveillance of U.S. persons and nationals,” consistent with the Fourth Amendment, the National Security Act of 1947, and the Foreign Intelligence Surveillance Act of 1978.

Worth noting - the Department of Defense generally does not engage in Mass Surveillance of American Citizens, that’s the province of the Intelligence Community (IC) which includes at least 14 agencies (although some are in the DoD), most notably the NSA and CIA. While this means that there would reason to include this issue in talks with the Federal Government as a whole, it’s not really an issue for DoD contracts per se - which leaves us with the real focus - Autonomous Weapons.

What’s the Problem & Where’s the Misunderstanding?

The problem here is that we have a mutual misunderstanding between the two parties in conflict and that misunderstanding centers around the capability / red line that the Pentagon is really interested in - AI Autonomy. But in reality, it’s not just a misunderstanding between Anthropic and the Trump Administration - the entire AI Industry and every government in the world are actually the same boat. No one has yet developed an agreed-upon set of definitions for what AI Autonomy represents (for military and non-military uses) and without such definitions, organizations end up talking past one another due to the murky and sometimes ambiguous language that they are using. What this means from a practical perspective is:

1. Any contract language for AI tools must necessarily be fairly vague without any such standards in place.

2. As a result, there will be misunderstandings and / or disagreements in relation to any potential AI ethical boundaries, (but not just ethical ones, as there might be licensing restrictions for certain types of AI use introduced as part of some company’s business model).

3. This confusion will extend into any AI legislation or regulations created by any government.

4. This confusion will also make it difficult to establish and manage AI Governance at an organization level.

5. And all of this confusion combined will make it difficult for anyone to measure how AI is really being used and / or restricted to ensure safety or risk reduction at any level (or Ethical Compliance to standards that aren’t really in place yet).

The basis of the Misunderstanding stems from the notion that AI Autonomy can be classified as a single thing. Upon even a minor amount of reflection, it quickly becomes apparent that AI Autonomy can in fact operate on many levels and being able create such a classification can then assist in AI development & Governance, Ethical Compliance and eventual measurement of how AI is being used. For example, a weapon could be autonomous, yet monitored with override capability or it could be fire and forget - or many other things as well. And if AI Autonomy is in fact more complex than a single definition, what exactly do we need to correct the situation? What’s needed and has already been started by several thought leaders in the AI Industry is an attempt to start an AI Autonomy Taxonomy (see below).

What is a Taxonomy? A Taxonomy represents the formal structure of classes or types of objects within a Domain. It organizes knowledge by using a controlled vocabulary to make it easier to find related information. A Taxonomy must:

• Follow a hierarchic format and provides names for each object in relation to other objects.

• May also capture the membership properties of each object in relation to other objects.

• Have specific rules used to classify or categorize any object in a domain. These rules must be complete, consistent, and unambiguous. (definition from Dataversity)

The DeepMind AI Autonomy Levels (Taxonomy)

As noted above, others in the AI industry have recognized this problem and started working towards development of a standard taxonomy to correct it. The first and perhaps best to date is DeepMind’s AI Autonomy Levels Whitepaper (see diagram below). While this initial effort took a fairly concise approach, it still represents an important first step. There are several variations to the 5 level approach (including one from Nvidia), but the question that arises from reviewing all of these variations is whether 5 levels is actually enough to ensure the type of clarity that we need to create and enforce AI ethical standards, Governance and legislation / agreements. It’s important to note that most of these Frameworks or Taxonomies are characterized as Agent Autonomy, although in reality viewing AI levels only in that context may be too narrow to suit our needs. The 5 “Agent Autonomy” levels posited by DeepMind (from their whitepaper) are:

• Level 1, Operator - At this lowest level of autonomy, the user is in charge at all times while the agent is available to provide support on-demand. In this sense, the user is the agent’s operator, responsible for driving much of the decision-making and long-term planning in a workflow.

• Level 2,Collaborator - This level emphasizes close and frequent user-agent communication and collaboration. Both the agent and the user can plan, delegate, and execute tasks to leverage each other’s capabilities and knowledge. L2 is the first level where the agent does not always “follow” the user around in the environment and can independently work on its own tasks while the user works on theirs.

• Level 3, Consultant - While L2 sees users and agents as close collaborators, L3 shifts more responsibility onto agents. The agent takes initiative in task planning and execution over extended time horizons. Users still have an active and important role in the agent’s workflow, but their involvement is more focused on providing feedback, preferences, and higher-level directional guidance rather than hands-on collaboration.

• Level 4, Approver - While the user maintains an active role in L3, their role in L4 is more passive. As an approver, the user is only required to interact with the agent when the agent encounters a blocker it cannot resolve on its own. This includes reaching a failure state that prevents workflow continuation, providing credentials (e.g., API keys, passwords) that the user did not share, or signing off on consequential actions.

• Level 5, Observer - The highest level of autonomy describes a fully autonomous agent that does not require, and comes with no means for, user involvement. L5 agents plan and execute tasks over long time horizons and make all decisions on their own. When they run into blockers, they repeatedly iterate on solutions until resolution or modify their approach to avoid running into the blocker in the first place. For transparency and auditing purposes, users can monitor the agent via activity logs, but cannot provide input nor change the trajectory of agent activity. The only control mechanism available to the user is an emergency off-switch that shuts off all agent activity.

Concerns with the DeepMind (and similar) Levels

While this is certainly a good starting point and has inspired many other similar attempts over the past year, there are several critical things missing from this taxonomy, including:

• It’s a little bit too general in nature.

• 5 Levels is not enough to capture the true complexity of the topic, unless these levels were split into sub-levels - unfortunately, the current structure may not lend itself well to doing that.

• There is one supreme concern here in relation to context. In other words, the environment or context in which the models are used has to be taken into account somehow when addressing AI Autonomy. Examples of where this is especially important include Healthcare and of course the use of Autonomous weapons. In other words, a fully autonomous Vacuum Cleaner should not be viewed the same as a Cruise Missile.

• The question of Oversight vs. Supervision vs. Approval is a little murky in this framework. Both Nvidia’s 4 level taxonomy and Turian’s 5 level Taxonomy take more generic approach to the definitions to help smooth this out, although neither takes context into consideration. The Cloud Security Alliance has a six level Taxonomy that borrows perhaps from the other three.

• Most of the Taxonomies fail to include both a level 0 (no autonomy at all) and a true Fully Autonomous level (e.g. one that wouldn’t require any human participation at all). These extreme and polar opposite levels need to be included in order to classify all AI capability being assessed / managed.

While some of the folks that have put these frameworks together have described portions of their taxonomies, in every case there’s at least a couple things missing in those descriptions to help figure out both how & why they’re structured the way that they are and how to use them (in various contexts). So, the first step in coming up with an Industry Standard AI Autonomy Taxonomy is to better explain up front how it’s being created…

Creating a new AI Autonomy Standard Taxonomy from Scratch

This process needs to begin with some principles, so here they are:

1. Any such standard taxonomy ought to apply to all / any form of AI (not just Agents).

2. Any such standard taxonomy must suit the needs of any / all organizations or individuals that might require it.

3. The taxonomy must allow for context-specific clarifications / differences.

4. The taxonomy must also include enough levels (or detail) to cover all of the anticipated Use Cases or ethical considerations the will be applicable for the foreseeable future (this should at least be considered as several decades into the future). This could be manifested through use of nested sub-levels as well, but they would of course have to be logically aligned.

5. The taxonomy must include both the starting point and end point of the AI Autonomy spectrum.

6. The Taxonomy must be general enough to support any Use Case, but specific enough to ensure clarity in regards to what’s being classified.

7. The levels and associated descriptions must be realistic and based upon existing scenarios or well-defined expectations. The levels must also acknowledge where gaps in shared understanding still exist (and be flexible enough to deal with them w/o becoming instantly obsolete) - this can include topics such as the definition of what constitutes AGI.

8. Per the last point, the assumption underlying this taxonomy is that while we currently do not have a true AGI capability yet, that some form of AGI will become available in the coming years and of course will play a major part in the potential application of any AI Autonomy in real-world situations. In other words, we do not need to reimagine this taxonomy later when AGI happens, we can and should account for it now.

A Proposed New AI Autonomy Taxonomy

With the above principles in mind, I am proposing the following Standard AI Autonomy Taxonomy…

• Level 1 - None: As the title implies, no AI Autonomy whatsoever is being used.

• Level 2 - Simple, Non-Critical AI-Supported Automation: This could include anything from using AI in manufacturing robotics to performing narrowly defined or simple tasks, to AI-enhanced BPM process automation. These tasks and related processes are run / controlled within well-defined (and typically existing SaaS) platforms. Critical vs non-critical classification is addressed below. (note, this level is further clarified by different definitions for Autonomy versus Automation - see below).

• Level 3 - Non-Critical Fully or Partially Interactive - This level occurs outside of those routine, simple tasks and typically operates within AI-specific platforms and require human support to perform. All non-critical Autonomy assumes non-harmful actions as well. “Harmful Actions” are defined later in this article. “Interactive” here implies that a human is involved in more than a supervisory or oversight role.

• Level 4 - Non-Critical Supervised - This level involves a dedicated supervisor which monitors AI activity full-time and redirects the AI as necessary.

• Level 5 - Non-Critical w/ Minimal Oversight - This level involves indirect supervision, potentially guided by alerts and notifications. As with all prior levels, this one retains approval and / or process termination authority.

• Level 6 - Simple, Critical AI-supported Automation - The difference here from the non-critical Autonomy level is that these tasks or processes can support harmful or other critical activities. Taking an example from the latest news (and the genesis of this article), when the DoD used Anthropic’s Claude to plan aspects of the current Iranian campaign, various simple (related) processes may have been automated but the end result were military attacks. This distinction then transcends planning from non-critical to critical. Also, beginning with this 1st critical level, harmful actions sub-categories are added to the taxonomy.

• Level 7 - Critical Fully or Partially Interactive - This is the same as level 3, but with critical tasks and / or harmful actions (including specific subcategories) added.

• Level 8 - Critical (actively) Supervised - This is the same as level 4, but with critical tasks and / or harmful actions (including specific subcategories) added.

• Level 9 - Critical w/ Minimal Oversight - This is the same as level 5, but with critical tasks and / or harmful actions (including specific subcategories) added.

• Level 10 - Total Autonomy - No human participation whatsoever.

Some important Notes

1. In this taxonomy, human Approval can occur at any level except level 10.

2. Also, in this approach, a process “kill switch” is also present in every level except level 10 (Total or Full Autonomy). And it’s important to understand that having a termination mechanism keeps the AI capability from achieving true total autonomy.

3. Context is provided as generically as possible here by splitting the levels between Critical and Non-Critical scenarios. These can then be further sub-divided as needed into any number of sub-levels. For example, all of the Critical Levels could each have Healthcare and Military sub-levels (as well as others).

4. The levels themselves focus on the degree of human interaction and control of the AI involved. This is both a generic and specific classification. For example, some of the other taxonomies included autonomy level descriptions that were focused on the AI (agent) rather than the level of human interaction or control of them (or in some cases included mixed approaches). While at first, this focus on human interaction may seem counter-intuitive when describing AI Autonomy, it’s actually quite practical from a Governance and role-based perspective. (and this is the most important aspect from the DeepMind Taxonomy that was borrowed here).

5. Harmful Actions - This is actually a fairly broad topic and will require an additional article to flesh out, but for our purposes here, this can be consdiered any actions that may involve intentional harm to humans or potentially to property and the environment as well. As noted earlier, this definition will require additional sub-categories in the taxonomy. These subcategories could then be mapped to an organizations canon of ethics much like Anthropic’s (with Mass Surveillance being considered a harm in one subcategory and Autonomous Weaponry in an another).

6. Autonomy versus Automation - This is addressed in one of our other articles here on Digital Perspectives.

7. Critical vs non-Critical Classification - This topic, like Harmful Actions, will require its own article to better define. For our purposes now though, it will refer to those processes or activities which an organization or culture / society deems to be especially important. For example, manufacturing or food service or retail related tasks would be considered non-critical, but something like Air Traffic Control would be critical. While we might consider critical as only pertaining to life & death situations, it likely won’t be that easy to classify.

8. There will also be situations where the same models or tools can be calibrated to shift from one autonomy level to another or in some cases, the same tool (with different instances) will operate at multiple levels simultaneously. This of course will require additional consideration when developing ethical guidelines, Governance and / or regulations for use of such tools.

In following articles, we’ll address some of the definitions related to this taxonomy in greater detail including Harmful Actions and Critical vs. Non-Critical tasks / processes. We may also take another stab at defining AGI, but this time in the context of Autonomy and this proposed taxonomy.

Copyright 2026, Digital Perspectives

Disclaimer - I work as an IT Architect. This role more or less requires a significant amount of skepticism in how to view the world; in other words, we typically don’t make assumptions without testing them and we also don’t typically take things for granted or take people’s word on matters. Architects are expected to challenge assumptions and test assertions of capability for validity. This approach or worldview fits with our role in helping organizations to reduce technology-associated risks. My articles here on AI related Philosophy or other topics does not make me an AI Skeptic, but rather reinforces the premise that I am and have always been a technology realist. The current generation of AI does have some value, but like most questions - it’s not an all or nothing scenario.

Evidence That AI is Not Doing Great

Let’s present the evidence that today’s Artificial Intelligence is in indeed in big trouble:

1. AI is not nearly as popular as the industry is trying to tell it is. Adoption rates by AI users are dismal and are being artificially propped up everywhere by combining AI models with existing productivity tools.

2. AI tools and companies are not making any revenue from AI: Again, much of the alleged revenue comes from the ‘forced adoption’ scenario described above while other revenues have resulted purely from round-trip financing.

3. AI is not nearly as effective as industry says that it is. Most surveys and studies for AI adoption (including Agentic AI adoption) show little or no actual productivity gains. Then there are the many many “hallucinations” (another way that we tend to anthropomorphize AI).

4. If AI was working, why does it need more processing power than all other IT capability on the planet combined? The premise and practice of Hyper-scaling is in itself the ultimate proof that today’s AI is completely stuck. Putting an engine the size of battleship into an SUV makes little sense.

5. Lastly, if AI were really working, it wouldn’t require this much hype trying to convince us that is was. Artificial Intelligence has now become “the mother of all hype cycles.” Each time another huge story drops proclaiming that AI will end work or destroy civilization as we know it, that messaging tends to reinforce the growing mythology that AI really does work as great as they all are saying it does (because how could it do all of those things if it was just - mediocre?).

Think about it for a moment; today’s top (LLM) models have perhaps 15x the trained inputs than they had in 2022/23 and utilize perhaps several times as much compute. Yet has ChatGPT improved by 15x or more across those model releases? The fact is that despite a huge bump in training data and tokens from versions 4 to 5, OpenAI’s model GPT-5 not only did not improve, many considered it worse.

Context Window: GPT-5 handles 400,000 tokens (roughly 600 A4 pages), while GPT-3.5 is limited to 16,385 tokens). GPT-5 represents a major leap over GPT-3.5, likely trained on over 30 trillion tokens compared to GPT-3.5's estimated hundreds of billions to low trillions.

Performance Downgrades: Users reported that the (GPT 5) model often feels like a “downgrade” or a “lobotomy” compared to GPT-4o, with worse reasoning in certain tasks and a “bland” tone in writing.

This type of real-world experience totally contradicts the AI Hype narrative, but OpenAI has not been alone in failing to see massive returns result from exponentially higher investments (in compute, model size and training). In fact, the main result of all of these experiences has been a doubling down on making even more massive investments by deploying data centers the size of cities (that consume as much power as whole states). This isn’t rational behavior, except if viewed as what it really represents; a huge deflection away from the true problem. This generation of AI is not capable of doing what it’s supposed to, and when that illusion crumbles so too does an economic house of cards.

Why Won’t it Work?

That’s the question, isn’t it? I’m not positing that AI (in its current forms) doesn’t work at all, but I am contending that it doesn’t work as advertised. The difference here is important and the more unrealistic expectations are also what’s driving the vast amount of economic activity currently surrounding AI. I’ve thought about this issue a lot recently, but the answer finally crystalized for me the other night while I was watching a documentary called, “The Thinking Game” which traces the history of Google DeepMind’s successes with AlphaGo and then the follow up with AlphaFold. AlphaGo was the AI model that finally beat the world’s champion for GO (an incredibly complex game played in the far east for more than a 1000 years). In between the outright hero-worshiping going on for DeepMind’s founder (who admittedly is pretty smart but he ain’t no Einstein) there was a good explanation for what Deep Neural Networks do and how Deep Learning works. More importantly though, the film inadvertently highlighted why games are different that real life - here’s the key…

While the game of Go is complex in regards to the total number of possible moves that can be made (more than atoms in the universe is the claim), they failed to mention that the game only has about 5 core rules. And in all of the other games that their models were teaching themselves, they were working with similarly simple situations in regards to the rules and environments involved.

This realization or revelation should have been obvious to all the genius-level folks at DeepMind (and yes I’m being at least a little sarcastic here because I don’t go in for the hero-worshipping), but it wasn’t. When they decided to unleash similar models on protein-folding, the (AlphaFold) model failed and is in fact still not much closer to solving how that process works. The thing is, that this is not just a good example of why we don’t have AGI yet, it also serves as a near perfect illustration as to why today’s AI isn’t working as advertised either. So, let’s review the reasons why current AI is failing with this example in mind:

1. Deep Neural Nets are good at determining simple rules in non-realistic environments (and then executing based upon those in similarly simplistic scenarios). Don’t get me wrong, this is still very impressive all by itself, but it is by no means “Intelligence.”

2. Conversely, this technology is terrible at dealing with complex environments and / or discovering complicated rules. And without those rules, it cannot begin to execute on related tasks or just does them very poorly.

3. It turns out that language operates by relatively few rules too and rules which can in fact be captured easily as formulas. This is how Computer Science began, from Turing to Shannon’s Information Theory. Chomsky later mapped out examples of such rules in a framework that he referred to as Transformational Grammar. This is why Large Language Models (LLMs) have had as much success as they’ve had to date, because whether some of this was built into the current algorithms or whether similar rules were discovered by the models the end result is that the rules help build responses.

4. But LLM responses are not knowledge and the process of creating them is not thinking. Language is more like a game than we thought, but it masks or translates something else in us that like folding proteins, cannot easily be converted into rules.

5. The reality that the current AI model architectures cannot handle consists of non-simulated environments that aren’t artificially constrained and include many complex and inter-dependent rules (along with all of the other elements which those rules are acting upon). This quickly translates into an almost Quantum level reality that oddly enough humans are good at navigating, but unsurprisingly AIs aren’t.

To summarize, while automating relatively simple tasks (and even combining a bunch of them using agents) under ‘controlled’ conditions is certainly within the scope of things that the current generation of AI can accomplish and this will have an important impact on the workplace and society - it’s still not much more advanced than previous task automation technologies. And it certainly is not intelligent, not yet anyway. Presenting it as something it’s not is problematic on many levels, not the least of which is that it tends to distract us from pursuing solutions that might in fact someday achieve true Artificial Intelligence. I understand why the AI Hype-pocalypse is happening (there’s a whole lot of money riding on it now), although I’m not sure why more people aren’t seeing through it yet. In the meantime, until the situation is clarified, pretending that AI is intelligent is likely going to cause real harm. My next article on this topic will explore the architectural limitations of today’s AI models.

Copyright 2026, Digital Perspectives

In the first eight articles of the AI Reasoning Architecture series, I covered:

• Part 1 - Defining (AI) Reasoning

• Part 2 - Designing and Measuring Reasoning Model/s

• Part 3 - Focus on Intuition and Continuity

• Part 4 - AI Reasoning Architecture Levels

• Part 5 - Architecting by Intention, not Accident

• Part 6 - ‘Rearchitecting’ AI Reasoning Models

• Part 7 - A Logical AI Model Architecture

• Part 8 - The Education Component (within the Reasoning Architecture)

What is Problem Solving Anyway?

This is a relevant question, not only for this component or even for an AI Reasoning Model as a whole, but it also apples to the question of what does or doesn’t constitute Artificial General Intelligence (AGI) - something that the industry itself has yet to adequately answer. We can start answering this immediate question perhaps by pointing out what Problem Solving isn’t first:

1. It isn’t prediction.

2. It isn’t pattern-matching.

3. It isn’t research or even simple analysis.

4. It isn’t learning.

5. It isn’t (just) compiling results (writing / creating, etc.).

Wait a minute, aren’t all these things part of problem-solving? Well, while they all be necessary for a person (or an AI) to solve problems, they aren’t actually typically part of the problem-solving process (or at least not the core of it). It’s worth stepping back a little further and asking what a “Problem” even means.

A simple problem can be vastly different from a complex one. A simple problem might be a mathematical equation that has one correct answer. A complex problem could be something like; “how do we get a man on the Moon in less than ten years.” See the difference? Both are problems that must be solved, but the scale (and complexity) can vary enormously.

Since humans have to deal with this level of ambiguity, so too must any AI hoping to perform human-like cognitive tasks. This is why I’ve assigned complex problem solving its own component in the AI Reasoning Architecture. As hinted at in the previous descriptions and in the above diagram, problems can also be mapped as “Problem Spaces.” Defining these Problem Spaces involves deciphering and / or structuring the context of the problem. For humans, this often occurs intuitively or sometimes involves application of various methodologies; whatever the case - figuring it out is a typical precursor to actually resolving problems, which brings us back to that definition…

Problem-Solving: Is the process of deconstructing requirements and expectations into their respective problem spaces and then applying various techniques to examine and assess ways to manipulate those spaces in order to determine whether anticipated outcomes can be met.

Purpose of the Solver Component

The primary purpose of this component is to offload targeted problem-solving actions to a dedicated and optimized set of capabilities and services within the model. As with the other components, the expectation is that it should work in concert with the other components in a coordinated, yet somewhat federated fashion (and be able to handle multiple types of problems and concurrent problem solving efforts). If we were to take subset of a subset of the ‘going to the Moon’ problem we might be looking at what is the best Orbital Insertion Method and then what is the best landing craft design. In the 1960’s, NASA came up with the LEM (Lunar Entry Module), but many designs approaches were considered and of course the entire premise (or problem space) was dependent on having decided which method was best for lunar orbit insertion first (a higher-level problem).

The (Problem) Solver Component is a recognition that to solve complex problems one must be able to:

1. Question the assumptions associated with the problem. (in the real world this could entail a dialog with the folks asking the question or requesting a solution or it could be an inner dialog complete with one’s own Devil’s Advocate”).

2. Reframe the problem in any number of different ways (this is sort of a conceptual ‘what if’ like process).

3. Determine how to best deconstruct the problem. If we were to use the ‘going to the Moon’ example, this would likely involve hundreds of thousands of separate elements.

4. Assign the proper analytical tools and begin resource requests as needed (from other components).

5. Manage analyses in tandem, rolling up results and then performing secondary levels of comparison across them. This would then lead to various alternative options which be assessed both internally and by human counterparts and also interactively reviewed by the “Director” component.

Elements and / or Modules of the Solver Component

The Solver Component within the AI Reasoning Model Architecture would essentially be divided between problem “deconstruction” and “reconstruction” elements (e.g. Problem Spaces & Resolution Spaces). In a future article, I will spend more time on both of these concepts, but the main idea for the employment here is as an analytical framework for managing various portions of a consistent problem solving process. Again as with previous discussion, the precise application of AI model types to this architecture is both open-ended and potentially dynamic with the real focus being the ability optimize any type of model to the designated task (while continuously working towards greater efficiencies).

Within the Problem Space boundary, we’d be looking at the following types of elements and / or services:

• Taxonomy Services - This is different from other Semantic categorization occurring elsewhere as it would be problem-specific. In our example of the Moon Race, we started at the main goal and had gotten down to LEM Design, but there are still many other levels to go down just for the LEM and of course relationships with problem elements elsewhere all the way up and down the taxonomy chain.

• Manifestation Services - This service allows us to better define the boundaries of the problem space as well as defining elements within it (preparing for relationship assignment). In the simplest sense, Manifestation Services allows the model to understand the provenance of the problem.

• Causality Services - It is often valuable to capture assumptions of how we think things are working or not working - this supports defining more sophisticated relationships later. In a Healthcare scenario, like the diagram above, this service helps capture the current state of understanding for how some disease / pathology operates. But for the Moonshot example, it might capture expectations in relation to fuel efficiencies for various types of orbital trajectories.

• Relationship Services - These begin the critical process of mapping relationships between problem elements. For example, better connecting fuel economy with orbital trajectories.

Within the Resolution Space boundary, the elements or services would likely include the following:

• Option Services - This is the main What-If feature of the model, taking the various descriptions of the problem space and other analyses and then doing internal ‘brainstorming’ (iteratively) to begin suggesting resolutions.

• Experimental Services - These could come before or after (or both) Option designation and represent simulated experiments to test out options and theories, again this would more than likely operate across iterations. Worth noting here of course is that in this Reasoning model, all such iterations must be documented for later auditing and validation (both within the model and externally).

• Recommendation Services - These recommendations could take many forms, but the idea is that this service gleans the best results from the options and experiments and posits the resolution/s.

There are also shared services, as with the other components and these include:

• Dedicated caches for both the Problem Spaces and Resolution Spaces.

• Various Assessors, Reviewers and Wrappers to help perform analysis, play Devil’s Advocate and create outputs.

• The Liaison / Iterator is a front facing problem ingestion service that doubles as problem oversight and (internal) orchestration lead - thus determining when and / or how many iterations within the problem chain must be repeated.

In my next article in this series, we’ll look at the Orchestrator Component.

Copyright 2025, Digital Perspectives

In the first seven articles of the Reasoning Architecture series, I covered:

• Part 1 - Defining (AI) Reasoning

• Part 2 - Designing and Measuring Reasoning Model/s

• Part 3 - Focus on Intuition and Continuity

• Part 4 - AI Reasoning Architecture Levels

• Part 5 - Architecting by Intention, not Accident

• Part 6 - ‘Rearchitecting’ AI Reasoning Models

• Part 7 - A Logical AI Model Architecture

Purpose of the Education Component

Disclaimer - in order to emphasize the points made in the article referenced above on Learning versus Training, the Component name has been changed from “Learning” to to the “Education” Component. The reason for this change should become clear as you progress though this article.

It’s also important to state up front here, that this proposed architecture does not represent what is commonly referred to know as Reinforcement Learning (even though some aspects of that might be included in one or more of the underlying elements being described here). Instead, what I’m positing in this proposed AI Reasoning Architecture is a series of complex components that better simulates human-like learning processes. I’ve also taken the opportunity to more clearly distinguish between “Training” vs. “Learning” as laid out in the Philosophical article on the same topic. The rationale for doing that is due to the need to split out some portions of the Reasoning Architecture to accommodate what are essentially different (if related) processes. The Education Component would work in tandem with specific problem-solving requests, (helping to facilitate their resolution), but it is also being designed to work in the background in what might be described as a “Life-long learning” paradigm.

It’s worth noting here that even though we’ve split out Training and Learning, they both still fit within the larger context of Education; just as it does for humans - thus ensuring for an end-to-end mapping to the Human metaphor. For our proposed model approach, we’ve represented each of these aspects of Education in the form of model “personas.” Just as humans adopt various personas in different contexts while retaining a centralized Self, so to will this model.

Elements and / or Modules of the Education Component

The elements of the Education Component are partially broken up across two primary subcategories with other elements being shared across both. The main two subcategories are:

1. Targeted Training - In this context, the combined elements represent a unified “Trainee” version or persona of the Self. The “Trainee” is actively taught in a curated process or processes; either by humans or other machine learning entities. This training can include both “Theory” and “Practice.”

2. Self-Directed Learning - Here, the combined elements represent a unified “Learner” persona of the Self. In other words, goals are self-set based upon direction from the Director Component and / or alignment with self-defined learning goals. This learning process is continuous and can also include both Theory and Practice; however, it is not externally curated.

Within both of these main categories, there is a further subdivision of supporting categories:

• Task-based Training or Learning - This might be thought of as how-to training; where a step by step process is conveyed and then memorized and / or practiced by the Trainee or Learner persona of the Self.

• Conceptual Training or Learning - This is the Theory part of Model / Self Education and again can occur in both Training and Self-learning contexts. Conceptual Education has a very wide-reaching context and the best way to think about it may be that it covers everything but the “how-to” tasks.

Targeted Training Specific Elements

These specific elements may take the form of Agents or not, but the idea here is that the elements help to frame whatever the how-to tasks represent.

• Expectation States - This is like showing the finished product or result of a process at its end state and perhaps also at various intermediary states along the way.

• Rule Capture - This captures how-to rules in the context of a full task with Expectation States. There are other “rule” related modules or agents in other Components as well and eventually all rules will end up in a comprehensive repository for ease of access by the Model.

• Validation - This utilizes the above elements to help ensure that Task-based steps or how-to training is reproduced or mimicked accurately by the “Trainee.” This is a measurement function and can also apply rewards.

Self-Directed Learning Specific Elements

Within Self-Directed Learning, there are several uniquely specific subcategories including:

• Theme & Path Tracker - This module aligns with the Liaison and other model components to track how various assignments and previous gained expertise are grouped into Learning Themes. This module also assesses all training activities as well (to determine where they may fit within the themes). A Path is graphical representation of how the Self travels on its Education trajectory. Note - that the roll up of Training and Learning partially occurs here because Self-Directed Learning has the higher “Self” priority for organizing all Education related activity and experience.

• Goal Setter - The Goal Setter is what drives the Self-Directed Learning Trajectory (path or paths), ensuring that it’s not random - but rather that it’s relevant to the formation of the Self over time. This module also assesses all training activities as well in helping to determine goals (per the previous point).

• Topic Generator - This module or function draws from both of the above to determine what the Learner should be studying on its own. Note - this can include both concepts and ‘how to’ knowledge.

Shared Elements

The shared elements between these previously described categories and subcategories include:

1. Component Liaison - This is where formal requests or directives enter from outside of the component and it tracks those requests through whatever education path is taken.

2. Retrievers - These are like search agents, charged with finding specific pieces of information. The pieces can be assigned individually or in sets.

3. Reviewers - These are also agents which evaluate what has been retrieved based upon a context derived from the larger activity that’s occurring. For example, if the retrieval results aren’t sufficient, (based upon Reviewer ratings), the Reviewer could reassign them (potentially adjusting the assignment as well to ensure better results).

4. Wrappers - This module or perhaps set of agents, would group retrieved results into more meaningful, larger contexts.

The Learning Component Cache

The Education Component would require its own permanent cache structure, composed of two halves:

1. The Practice Cache - This Cache includes all information associated with the Trainee experience, but it could also include any how-to reference information (examples of how others had accomplished similar tasks).

2. The Concept Cache - This Cache includes all Concepts encountered by both the Trainee & Learner related activities - e.g. all Concepts encountered in the Model’s Education history.

Each of these would retain context and timing-relevant information in the Cache while it was needed; then based upon various triggers, less relevant information from this Cache would be pushed to the equivalent structures within the Long-Term Memory Component or Repository.

Conclusion

The goal of the Education Component is to allow a model to be both trained and to learn continuously and to have all of that managed in the context of an evolving model Self.

Next up, (article 9), in our article series on AI Reasoning Model Architecture is the Solver Component.

Copyright 2025, Digital Perspectives

In the first six posts, I covered:

• Part 1 - Defining (AI) Reasoning

• Part 2 - Designing and Measuring Reasoning Model/s

• Part 3 - Focus on Intuition and Continuity

• Part 4 - AI Reasoning Architecture Levels

• Part 5 - Architecting by Intention, not Accident

• Part 6 - ‘Rearchitecting’ AI Reasoning Models

This article series on AI Reasoning was itself also based partly on a previous article series here on AI Philosophical Quandaries, (and I will get back to this series again soon):

1. “Intentional” versus “Accidental” Artificial Intelligence.

2. “Collective” versus “Individual” Intelligence.

3. Reasoning vs. Prediction.

4. Automation vs. Autonomy

5. AI Utopia vs Dystopia (Boomer vs. Doomer)

The Logical Reasoning Architecture, part 1: The Director

In the previous articles in this series, I identified a number of “Components” that might exist within a new type of intentionally designed AI Reasoning Model Architecture. I pointed out some of the flaws with current Reasoning Models; (although in many ways some of them have been quite successful to a point) most of those flaws stem from the fact that their design so far been approached in a somewhat ad hoc manner. There is a legitimate debate to be had as to whether the ad hoc approach might end up being more innovative than a deliberate one, (and this harkens back in AI to the dichotomy between the use of symbolic logic versus neural net models), but in this particular context, I think that this debate may miss the real point. And that point is that deliberate design doesn’t necessarily favor one approach over another (as was the case in that earlier AI design debate); it’s instead an architectural process that ensures that all avenues are properly explored within a well-defined context. And that context can and should include specific expectations for outcomes that are separate from any methods required to reach them.

Logical Architecture - Within IT / Data Architecture, a Logical Architecture is the middle level of detail; still abstract, but more specific than a Conceptual Architecture, yet less detailed than a Physical view.

So, let’s look again at the “Director” Component in this proposed AI Reasoning Model Architecture. This theoretical self-contained model is in actuality, a system of systems (or model of models) ecosystem, bounded in discrete instances.

As noted in the previous articles, this particular Component is meant to serve as the “Self” for a Reasoning Model. “Self” here refers to both Continuity and Orchestration oversight from a unique perspective; pointing to processing efficiencies and the gradual collection of insights over time. What this implies is that in each version or instance of this type of model development will likely follow a unique path resulting in individual differences that are akin to the creation of what we might think of as a “Self.” This is precisely the type of model “plasticity” necessary to escape the current AI training tyranny of having to learn all knowledge in the known universe in order to answer a simple question.

So, what’s in this Director Component? I posited several items in the previous article and will expand on that a bit here:

1. Component & Model Liaison. This represents the entry point for formal interaction into the Self (both at the Component and Model level) and potentially the starting point for assigning problem-solving tasks. This module would likely coordinate with the Continuity Manager in helping to make assignment decisions and / or communicate with external elements to clarify the request/s.

2. The Policy Module. This is a carryover from current Reasoning Model architectures and represents a sort of individual Canon of Ethics. Where the Director’s Policy Module will likely differ is in; a) the ability to interact with an external community version of the Canon and b) the ability for the Director to evolve its Ethics and grow over time.

3. Memory Caches. This would likely involve both permanent and temporary caches - the permanent one/s being especially important as a place to quickly reference specific insights gained over time.

4. Continuity Manager. This component must support accessing problem, rule and process step indexes as well as other domain specific ‘shortcuts.’ This in combination with the Caches will support “Intuitive Reasoning.” The short definition for this Intuitive capability is; “reasoning through applied insight.” In practical terms, this module or model (or set of models) would support rapid review of collected insights combined with pattern collection and review and potentially even the rapid creation of some sort of visual representations or “problem maps.” All of these activities and resources, collected over time and semantically categorized build a Continuity Stream unique to that “Self.”

5. Incentive Manager. This might also be thought of a “Goal Manager.” Again, this is a holdover or repurposing of existing model architecture approaches. The difference here of course is that the model itself through this module is helping to define its own goals and also specific types of rewards. This in combination especially with the Continuity Manager should help to grow the individual or Self over time.

6. Rules Manager. Each time that a Reasoning Model solves a particular problem, it’s likely that rules (think Business Rules) with be both identified and / or defined, (this will typically occur in other parts of the model but can be collected here for quick reference later). This module can also take advantage of repositories of existing rules as needed. The more unique rules that are identified or created, the more the Self differentiates itself from other Self Instances.

7. Self Assessment Manager. This module would be tightly coupled with the Incentive Manager and of course leverages many existing AI model elements. The difference here would be the ability to adjust measurement techniques as needed w/o the need to rearchitect the model (as currently tends to be the case). Again, this module could interact with any number of external assessment paradigms (just like humans do), to inform it’s choices. Those choices would be made based upon defined goals, initially provided measurement exams / paradigms and likely some human and model interaction as well.

8. Preference Manager. This is perhaps where a personality of sorts for a model Self could begin to emerge. The purpose for this module is to help guide the development of various specializations based upon the growth of insights accumulated by the model. “Preferences” in this context refers to tendencies toward using those tried and tested approaches to solve specific types of problems based upon a history of successes in that regard. It’s worth noting here that by formally acknowledging such tendencies and potential model / Self bias, the question of model bias can brought to the forefront and reconciled as needed with both the Policy Module and Incentive Manager.

9. Semantic Manager. This module would be dedicated to discovering and / or creating the Semantic Framework for structuring all model “Knowledge.” This would cover everything from internal Data Governance to the creation of Taxonomies or Ontologies to help categorize & assign information. Again, this module could potentially reference external sources as well, incorporating them as needed and then adjusting its own view or framework.

As we can see, the Director Component will likely be the most complex part of the overall Reasoning Model Architecture - a sort of Frontal Cortex for this “Self” brain as it were. In general, all of these Director “Modules” would be designed to grow and change over time with model instance-specific experience. The choice of the types of AI models (and / or related code) that can be applied to fulfil these module functions is both up for exploration and likely to change over time - the design goal being that determination of the best model admixture should be agnostic in nature.

Model Integration at the Component Level

As you might be wondering, what would be the glue holding together this complex “Self,” which in fact includes much more than the Director Component. We need to thus consider the levels of intra-model integration:

1. Integration within each Component (across the various modules as identified above) and

2. Integration across the Components within a single model or Self Instance.

3. Integration with external elements (from either inside of components or through unified component interfaces).

While I’ve been referring to all of this as a defined instance with instance boundaries; it’s important to keep in mind that this description is a little flexible as it will necessarily be deployed in both Cloud and local contexts. We could potentially view each “Module” within a Component as a “Service” and thus manage the integration across them using standard API calls. We could then extend that to API calls between the various components as well, but then the question would be whether a Component only makes unified calls in or out or whether component modules could reach out individually to other model components (and potentially even external elements). I think both cases can and would occur in various contexts depending on how the models manage oversight and orchestration of specific tasks.

In the next article in this series, we’ll take a look at the AI Reasoning Model Learning Component.

Copyright 2025, Digital Perspectives

• Part 1 - Defining (AI) Reasoning

• Part 2 - Designing and Measuring Reasoning Model/s

• Part 3 - Focus on Intuition and Continuity

• Part 4 - AI Reasoning Architecture Levels

• Part 5 - Architecting by Intention, not Accident

In Part 5, I introduced the idea of architecting (or rearchitecting) AI models to reason more or less from scratch - by intent rather than accident. While I didn’t cover it in that article, many of you might be thinking - well, aren’t there numerous AI Reasoning Architectures / Models already on the market? Not surprisingly, I’m going to answer this by saying yes - and no. There are a growing number of “Reasoning” models on the market, including ones from OpenAI and Grok as well as DeepSeek, but they haven’t actually been architected from the ground up to be true Reasoning models. What’s the difference? That’s what we’re going to cover in this article.

Today’s Generation of Reasoning Models

There are number of excellent resources available online on this topic and I’d point you to Cameron R. Wolfe’s Substack, Deep (Learning) Focus as a good starting point for more details on it. A brief summary is that while these models are different from and thusfar have proven much more successful than their traditional LLM counterpart models, they all still suffer from a number of common flaws and all of those are directly related to the Architecture & related Assumptions.

Flawed Assumptions in Today’s (AI) Reasoning Models:

1. That Reasoning can be limited to “Ground Truth,” or easily verifiable problems. Also, Reasoning in the context of all of these models hasn’t really been defined, which in turn led to problems with the measurements that they’re using and of course the Architectural Assumptions. Instead, the definition is the measure currently being applied - which is a bit too circular for me.

2. While problem solving is both the proper context for and the end goal of Reasoning, achieving a correct answer doesn’t necessarily indicate that a Reasoning process was used to derive it. The distinction is actually quite important and likely will make the difference once we get to the point of declaring whether AGI has truly been reached or not.

3. That true AI Reasoning can or more importantly should be achieved by throwing more compute at it. While it may seem intuitive to assign more resources to a more complex process, the opposite is actually true in the case of Reasoning. In other words, if our goal is an efficient human like capability - this assumption is taking us in the wrong direction.

Obvious Architectural Flaws:

1. It’s not clear how much of any of these models were designed for purpose or by intent, but it doesn’t seem as though any of them were - yet. While various model elements or types of models have been combined with differing reward and policy paradigms, these seem more like additions and adjustments as opposed to a full Reasoning-focused redesign. I might be missing some players here who’ve gone farther, but I’m just taking into account the leaders for now.

2. And Efficiency is still the big problem. The main premise for at least some of these models seems to be that longer compute time = Reasoning. And for DeepSeek it may be model size (671 billion parameters). In both cases (and these may in fact be combined), we’re still going in the wrong direction. Reasoning’s greatest potential is or should be in making AGI reachable in a more cost effective, explicable manner. Yes, we may be able to simulate Reasoning through massive hyper-scaling, but at what cost and will it actually be Reasoning or just an approximation?

3. Which takes us to the last problem - long form “Chain of Thought.” While this might not be associated with all current Reasoning Models, it seems to be a prominent feature and by its very nature will likely make deciphering how we get answers / solve problems even more difficult than it is already with LLMs. In other words, we need to build in more auditable features - this will benefit both the models and humans using them.

4. Training Assumptions for AI need to be completely reconsidered. The current approach (of using the entire sum of Human Knowledge to train a model) is not sustainable and will flatline all future AI development if continued. In other words, a single model should not require any more than the standard knowledge set available to say an average college-educated human in order to be able to engage in Reasoning-based problem solving.

Do I think that this crop of recent “Reasoning” models is a step in the right direction (despite the flaws)? Absolutely, and here’s why…

• Most importantly through the tech industry acknowledgement of the Reasoning deficiencies in the current LLM-focused view of AI.

• And demonstrating various ways that it might work has already managed to improve the entire crop of other AI LLM-focused products. In fact, it’s quite likely that LLMs will all become like these Reasoning models sometime soon.

• The current Reasoning model approaches have done a good job in helping us to pick out what’s missing or how a more thorough redesign might proceed. Which takes us to…

What’s Missing?

I highlighted a number of things already in the conceptual view above that I believe are missing, but let’s take a deeper dive.

• In the “Director” component, we might combine an individual and evolutionary “Policy” module. The biggest gap missing outside of the model in relation to Policy are industry standard Policy “Canons” - these can serve both as standards and as reference resource or starting point for the Individual Policy Modules within a Director Component.

• Also in each of the components (as well as any sub-instances that are spun up on demand and later archived) there will likely need to be real-time memory caches. Each of these in turn would interact with the long-term Memory Component to help provide / support Continuity.

• Speaking of Continuity, there will need to be another feature with the Director module which we could refer to as a ‘Continuity Manager.’ This component must support problem, rule and process step indexing as well domain specific ‘shortcuts.’ This in turn will support Intuitive Reasoning, but we’ll need to come back to that after the Logical Architecture is presented.

• There also needs to be more focus on how specifically to make each component work with the least amount of compute possible and how to ensure that each ‘Chain of Reasoning’ or Problem-solving event is managed (both from an auditing and active oversight perspective).

• Reward Systems also need to be rethought. This is something that I see being handled by the Director Module, but also as in the prior case with Policy, through sharing with external reward “frameworks.” Eventually, the Director module should be able to define its own rewards based upon Policy guidelines (including those policies that they develop themselves).

• The focus on how to build rules and capture problem solving steps will likely need to span multiple modules. “Master Rules” for handling methodology would live in the Director (and in Memory), Dynamic Rules would be ‘discovered’ in Learning modules and also ‘invented’ as part of the Solver components. There again could be access to external rule repositories as well.

• The Orchestrators could follow a multi-modal, ‘Mixture of Experts’ approach as well as coordinating assignments to other modules. These MOEs could also serve as panels for option interrogation and validation.

• The Learner component/s would involve Reinforcement Learning Models, most of which would be spun up as needed and then archived, but the core would group itself around a “Semantic Knowledge Framework,” which would also take advantage of the Memory Component.

In part 7 of this series, I’m going to build out the ‘Logical View’ (for the AI Reasoning Model Architecture) of these gap considerations that have just been described. I’ll also add some additional description that will help to illustrates how each feature or component addresses the various Assumption and Architectural Flaws mentioned in this article.

Copyright 2025, Digital Perspectives - part of the Semantech Inc. Media Group

• Part 1 - Defining Reasoning

• Part 2 - Designing and Measuring Reasoning Model/s

• Part 3 - Focus on Intuition and Continuity

• Part 4 - AI Reasoning Architecture Levels

Part 4 covered the four architecture levels that are necessarily involved with AI Reasoning and I honed in on Levels 3 & 4 as the opportunity space for AI (e.g. where Reasoning will actually be architected and will eventually achieve an actual Return on Investment). Today, I’m going to focus on Level 3 - AI Models - and as promised we’ll start with what’s wrong with today’s models (and de facto also with their architectural assumptions) and then I’ll move over to architecting Reasoning with “Intent.”

What’s Wrong with Today’s LLMs?

Large Language Models are the end all be all, aren’t they? They accomplished everything that we ever dreamed up, didn’t they? And because they did, we have to stay on this exact same path, no matter how inefficient it is, no matter how much it cost or how little it’s actually now progressing towards its actual goals… Obviously these are all fallacies, but to understand why, we need to go back to the beginning - the first expectation and first objective measure - The Turing Test.

The Turing Test, originally called the “Imitation Game” by Alan Turing in 1949, is a test of a machine’s ability to exhibit intelligent behavior equivalent to that of a human. In the test, a human evaluator judges a text transcript of a natural-language conversation between a human and a machine. The evaluator tries to identify the machine, and the machine passes if the evaluator cannot reliably tell them apart. The results would not depend on the machine’s ability to answer questions correctly, only on how closely its answers resembled those of a human. - Wikipedia

So, what’s wrong with this picture (and I’m not referring to the movie of the same name with Benedict Cumberbatch)? Besides the test (or measure / goal) being incredible subjective, it clearly puts us on path for Intelligence by Accident rather than by Intent. Well, isn’t that the same thing? Isn’t a simulation or imitation of Intelligence actually Intelligence - isn’t that what people do too? The answers are; no, no and no.

1. Intelligence and an Imitation of intelligence are no different than a human and an imitation human (robot, dummy etc.). One may appear to be a very convincing copy of the other, but they aren’t doing the same things (e.g. they get to their outputs or proofs differently).

2. Is a simulated Intelligence, intelligent? Yes, it is, but not in the sense of being able to replace human thought because it does not involve reasoning as we know it. A calculator is intelligent too, but there are very many levels and types of intelligence.

3. And no, people aren’t ‘simulating’ intelligence; they’re exercising an innate capability - that’s different.

The top-level problem then with Large Language Models (LLMs) is that they’re geared towards a Turing approach to Intelligence - in other words, they’ve been built to mimic human-like responses or outputs based upon probabilistic assessments of an ever-growing context pool of training data (e.g. Mega-Context). This signifies the following things from an architectural perspective:

1. They’re designed for the wrong intent (imitation versus reasoning).

2. Their success is dependent on accident rather than intent, (imitation doesn’t necessarily require an understanding of something in order to mimic it).

3. Any improvements in accuracy are dependent upon an exponentially growing context pool; which in turn makes them both inefficient and incredibly expensive.

How do LLMs Work?

I’m not going to go too deep here in deciphering LLM Model structures (and I’m speaking very generically about them) as others have done it much better than I could - but it’s worth visiting the key assumptions behind it. LLMs are ‘prediction models,’ to some extent not too much different from the principles first explained in Shannon’s Information Theory. LLM’s, like Information Theory, uses various mathematical formulas to optimize ‘likely’ best results for certain contexts. These Foundation models use the context of all existing data (and yes, the context pools are growing that large), to accurately predict the most likely next best response one character or token at a time - building an mimicked response to questions in real-time. The thing is, as noted in previous articles, there’s no continuity or memory here and without those you can’t have Reasoning - only a facsimile of it.

As you can see in the diagram above from Wolfe, the architectures of the Models themselves are now extremely complex and it’s important to understand that Level 3 (the model level) is not the entire LLM or AI Solution - that’s level 4. The Model level or layer is though where the vast majority of the processing is occurring (as it’s being massively distributed across all of those chips, servers and datacenter). LLM Models and the surrounding solution elements are in fact massively parallel cloud-based systems.

Why LLMs Aren’t Actually Working

While the obvious capabilities of these models have demonstrated that they are successful in doing a lot of things that most of us didn’t think that they would be good at, they aren’t actually succeeding in their core goals of reproducing human intelligence in several key areas:

1. LLMs are not AGI and no matter how much compute gets thrown at them, they never will be (not if we’re solely reliant upon the current model architypes).

2. LLMs may have already reached and passed their peaked efficiency. In other words, the level of accuracy on output versus efficiency is now headed in the wrong direction. A human being is now infinitely more efficient than any given LLM.

3. LLMs are not actually designed to learn over time, the process of training and then ‘fine-tuning’ models occurs on a meta scale and they are largely one-off efforts.

4. As as result of these considerations and more, with LLMs we are in effect designing AI systems which require of the entire sum of knowledge of the human race plus untold amounts of newly produced Synthetic Data to reach levels which are still below AGI and thus have produced some of the least efficient machines ever invented.

While the models themselves are incredible in many ways, they cannot and will not overcome their flawed architectural assumptions - and those flawed assumptions have in turn spawned a number of critical business-related assumptions that are now poised to seriously impact our economy; including:

• The notion that AI Model accuracy and thus improvement can only come can from more data and additional infrastructure hyper-scaling.

• The need to continuously fund datacenter and chip purchases to feed that Hyper-scaling, which then leads to circular financing and artificial revenues and valuations in industry - thus leading to the massive ($20 trillion) AI Bubble.

• The redirection away from actual AI innovation and towards AI Groupthink - taking all investment dollars with it and placing all of our bets on a losing horse.

What’s the Alternative? What should AI Models look like?

We’ll start by defining some Architectural Principles to guide us:

• AI Models should be designed for the correct ‘Intent’ and that should be to create a Reasoning Architecture.

• AI Models should be efficient, both in terms of data and power consumption. This means that they should be “Architecturally Elegant.” (like Humans are).

• AI Models must necessarily be dynamic. This means that they need to be able to exist at multiple levels and scales and to evolve over time.

• AI Models should strive for true intelligence, rather than imitation - this is the only path whereby they can achieve their potential or an ROI.

• AI Models should use Nature as a pattern and apply more standard sub-patterns. This can occurs in multiple ways and at multiple levels.

What Components would satisfy such an Intentional Reasoning Model Architecture?

If we assume that the model that we’re trying to build will require several different types of capabilities combined in some fashion to achieve Reasoning (which is where we started a few articles ago) and then take the Architectural principles listed above and start translating them into potential Architectural Components (within a High Level Conceptual Architecture) then a Reasoning Architecture might include the following (each compromised of potentially different types of AI):

1. A Director (permanent) - this component serves as the liaison to the outside; receiving requests, interrogating them to achieve greater clarification, making assignments to other components and more importantly, building an index (and likely a cache) of “Continuity.”

2. Orchestrator (temporary) - this component is spun up on request to organize a specific request response. It coordinates further clarifications from the Director, and manages the assignments to other components or subcomponents and constructs the response through it’s interactions with them. There can be multiple orchestrators running at any time (and for any duration). Once complete, they are archived, but could be resurrected and repurposed for similar requests.

3. Problem Space Learner (permanent) - This component is focused around reinforcement learning of problems that are contextual to any given ‘Self,’ but also involves directed learning potential across any context / topic. It includes a Continuity Management capability that works in concert with both the Director index and 'Self Memory. It can spin up temporary clone instances to focus on certain areas. It’s main output would go to the Problem Solver during individual requests, but across requests it would be populating the Director & Memory.

4. Problem Solver (permanent) - This component is more multi—purpose and analytical. This is where pattern matching and research from the Learner/s gets applied to specific AoAs or other types of problem solving. The results (and how they were reached) then go back to the Director (through Orchestrators) and are also stored in Memory. As with the Learners, these can be cloned temporary instances as well.

5. Memory (permanent) - This is the data or context pool for the Self, but not necessarily the Model Cache (which will likely live in the Director instead). The Self’s Memory becomes over time its most valuable ‘training context.‘

This set of generic components, combined with a single “Self” instance (boundary) is just a starting point for a standard, intentional (and Nature-inspired) AI Reasoning Model Architecture. In the next article, we’ll review this Reasoning Model architecture in greater depth, including detailing the assumptions driving it. While many might think that the various current variations on LLM (Model) Architecture are already doing some or much of this I’ll say - yes and no. Yes, they sometimes call what they’re doing something similar or in fact components may perform similar tasks, but the main difference here is that for the most part those attempts were not architected from the ground up intentionally to achieve what we’re talking about achieving here. That makes them fundamentally different.

Copyright 2025, Digital Perspectives

• Part 1 - Defining Reasoning

• Part 2 - Designing and Measuring Reasoning Models

• Part 3 - Focus on Intuition and Continuity

Architectural Levels

AI is often referred to as some sort of monolithic single thing, but this couldn’t be further from the truth. Artificial Intelligence solutions exist within a complex multi-level or layered architecture (which we can traverse from top to bottom or vice versa). If we simplify the categorization of what’s involved with this larger ecosystem, we end up with roughly four levels or layers (and this follows a bottom up approach with compute at the bottom and software at the top):

1. Chip - At the very bottom is the basic compute mechanism or CPU / GPU. The term AI chip is somewhat deceptive as there isn’t necessarily any AI capability inherent in their architectures, but rather that they’ve become optimized for a certain type of processing favored by current compute-intensive AI (LLM) models.

2. Datacenter - This level combines all of the various infrastructure elements; servers (hosting the chips), as well as telecom support and the virtual Cloud ecosystem for service delivery. (as you can see, we could easily split this out further if we wanted to).

3. Model - This is the core of an AI solution and can include one or more unique models (unique both in terms of its architecture and the data used to train it). Most folks tend to equate this with an LLM, but that’s a mistake and I’ll discuss more about that in a minute.

4. Solution - This is what resides on the Datacenter, using those chips and is dependent upon the model/s. It’s a combination of model/s, data, services and whatever goes into making a proprietary AI product offering. While these initially were mainly focused on supporting the “Frontier or Foundation Models,” the application layer as it were is growing in many directions at once right now - and is extending into both Middleware and all types of SaaS offerings. This trend will continue.

Out of these four layers, nearly all of the investment and much of the attention is being paid to the first two (some are saying to the tune of about $400 billion this year alone and perhaps more), yet nearly all of the true opportunity lies with the latter two. While there have been improvements in both Foundation and Frontier models and AI companies are partnering with the traditional software giants to create more interesting solutions atop those models, most of the money thusfar is not going into that activity. And the reason why is that the entire tech industry has now bought into the myth that the only way to evolve AI is to hyperscale it. There’s a lot packed into that premise and we’ll get back to it in a minute.

For our purposes, the focus on a Foundation Architecture for Reasoning Solutions will involve layers 3 and 4 only. Granted, this new architecture focus will impact the first two layers too, but that impact will be the inverse of what’s happening now in AI (e.g. it will move investment away from inefficient and ultimately unaffordable infrastructure back to where the real value lies).

The Main Value Proposition for a Reasoning-based AI Architecture - It moves us from; ‘wonder at the unexpected’ to ‘verifiable confidence in consistency.’ Once we take the mystery out of the solution, we can reliably predict how much it will cost and how much it can really earn over time.

While that last sentence sounds like common sense reason - it is diametrically opposed to the current industry path for AI.

Where do we start with a Foundation Architecture?

The obvious answer is the Model/s - layer 3. The reason why of course is that layers 1 and 2 merely feed 3 and layer 4 is wholly dependent upon 3. So, we need to tackle the AI models first - as they are the source both of all current success as well as the bottlenecks. The current dependence on models that we don’t understand and that require exponentially more resources to produce only marginally better performance would seem to be a non-starter, yet that’s the current focus and industry path. While Large Language Models will certainly be involved in any Reasoning Solution, they won’t be the primary focus. In the next article in this series, I’m going to take a deeper dive into what’s wrong with the current LLM models (why they won’t work and won’t pay off the current investments) and what I think will replace them (both in terms of individual models and model ecosystems).

Copyright 2025, Digital Perspectives

I’ll start with Continuity as I believe it’s a little more straightforward. Rather than provide any industry-standard definitions here as a baseline, I’ll jump right into what I think it represents. Why? Because the term “Continuity” is fairly lexically ambiguous and can be construed as a many things, but I’m contending that we can assign it some specific characteristics in relation to AI design & execution. When most people hear the term Continuity, they probably tend to think of that as “being consistent over time.” And that does apply, here - but then again - what does that actually mean (especially in the context of Reasoning)?

1. Does it mean that individual Reasoning processes (or threads) should behave consistently? well, yes

2. Does it mean that Reasoning itself can occur across time spans? (both individual processes and sets of related ones). yep

3. Does it mean Reasoning (skills) can improve over time? yes, that too

4. Does it imply consistency measures? definitely

5. Does it mean that AI Reasoning should draw upon experience, memory and even intuition to reach its conclusions? Yes.

With that as a backdrop, let’s try to define what AI Continuity represents, based upon (hopefully) more measurable characteristics.

Artificial Intelligence Continuity - This involves the ability for an Intelligence to consistently engage in Reasoning over time, (utilizing dynamically evolving methodologies and skills), both in the context of solving individual problems as well as in its overall problem-solving capabilities. AI Continuity is at least partially dependent on the underlying processes being made ‘explicable,’ such that auditors (human or non-human) can follow the Reasoning Path from beginning to end.

This of course requires a follow-up definition:

Reasoning Path - This represents the analysis and decision-making chronology (and related actions) that occurs once a problem has been assigned to an Artificial Intelligence.

Now, for the Hard Part - Intuition

For the baseline here, I’m just going to plug in Google’s AI generated definition (it seemed somehow appropriate):

Human intuition is the ability to understand or know something immediately, without conscious reasoning or thought. Also known as a “gut feeling” or “instinct,” intuition involves the unconscious mind rapidly analyzing patterns from past experiences and knowledge to form conclusions that seem to emerge spontaneously. While not a magical process, this subconscious processing allows for quick, holistic understanding, particularly in complex or uncertain situations, though it can be influenced by biases and past experiences.

…and here’s what it had to say about AI Intuition:

AI Intuition, also called Artificial Intuition, is the emerging capability of artificial intelligence to draw conclusions and make decisions by recognizing subtle patterns in data, rather than strictly following programmed rules or needing exhaustive analysis. While it mimics the human “gut feeling,” it does not involve consciousness, emotion, or self-awareness. Instead, it relies on advanced computational and learning methods to process vast amounts of data at high speed.

I’ll condense these both and translate: “Magic happens in the brain for humans, and it happens in models for AI.” In other words, neither definition is particular helpful in getting close to designing or measuring any sort of AI Intuition. The closest that these both get to something concrete are the references to “Pattern Matching.” So, now let’s ask some questions.

1. Is Human Intuition really based on Pattern Matching? Not really, I’ll explain in a minute.

2. Is current AI (pattern matching based) Intuition anything like Human Intuition (and does that matter)? No, it’s not, but it’s worth noting that we still don’t really understand Human Intuition yet either - which is a bit of a dilemma. And yes, it does actually matter.

3. If Instinct is important (in Human Intuition), where does that actually come from? It comes from the “Self.”

4. Does Intuition in fact require some level of Self (e.g. Self-Identity) to occur? I’m going to argue here in a minute, that yes it does - and that it’s also supported by Continuity.

5. Will adding more processing power (trillions of $’s worth of more chips and more energy-sucking data centers) magically give us AI Intuition? Nope

Ok, let’s look at Pattern Matching. This is something that we know AI is already pretty adept at and it is also included in my definition as a measurable component for (AI & Human) Reasoning. But can we conflate the two (e.g. Intuition & Pattern Matching) - no, we can’t or at least we shouldn’t. Granted, Pattern Matching is likely required in order for Intuition to operate, but they aren’t the same thing. Why not? Because Human Intuition also includes a wide variety of complex, Abstract Thought (such a wide array in fact that few have managed to catalog it all). In other words, Pattern Matching is not like Human Intuition (as far as we understand it) because our Intuition is obviously much richer and more complex.

That brings us to “Instinct.” Many people when they think of this might picture some wildlife documentary showing an animal engaging in a non-learned behavior (like ants building a mound). But, in this context, I think Instinct refers to lessons learned that have been reinforced well enough that they allow for immediate reaction (e.g. decision-making). For this to work though, I think it really does have to be focused around an individual’s experience - Instinct in this context is personal, not genetic. And if it’s individual and personal, it necessarily has to involve at least some type of Self (or personal identity). While, something like this might be simulated without achieving a Self, it’s likely that such simulations would lack certain key capabilities that any entity possessing a Self would gain from having the Continuity of Self to lean on. Time for another definition…

Continuity of Self - Consistency that’s partially enabled through the mechanism a continuous identity (maintained over time). Such an identity can of course evolve over time, just as any other Self could - but the core identity would remain throughout its ‘lifespan.’

While there are many who are betting that AGI will require neither Intuition or Continuity (or even Self), they’re wrong. Yes, they can spend trillions of $’s creating the most inefficient intelligences in the Universe, but those will still lack certain key capabilities that most of us realize will actually be necessary to take the next steps in Artificial Intelligence. Let’s take a shot now at defining AI Intuition.

AI Intuition - A capability that relies on Continuity of Self to help manage Reasoning Paths in a manner that reflects the lessons that the AI Self has learned over time. This approach includes a variety of learned skills, knowledge and techniques, (such as Pattern Matching, Internal Dialect, Concept Visualization as well as others), and can evolve over time. It cannot occur without that body of learned experience to draw upon - any such AI capability that performs ‘one-off Intuition’ would in fact merely be a simulation.

In a future post, I’m going to take a deeper look at what those “Other” (Intuitive) Techniques and Skills look like. In the next Article, I’m going to start examining what a Reasoning Architecture might look like.

Copyright 2025, Digital Perspectives

Reasoning (a proposed new definition) - The related set of processes wherein a human or non-human intelligence is able to identify and resolve specific problems or challenges using a variety of dynamic techniques or capabilities. Reasoning typically involves the following components in helping to solve any given problem: a) pattern identification, b) analyses of alternatives, c) application of learned experience (intuition), d) application of learned knowledge, and e) application of learned behaviors. And Reasoning can occur at multiple intensities (depths and levels) and across various durations (instant versus extended, etc.).

I explained in the previous article how I came up with this. But now that we’ve got it, how do we use it (or something like it) to make and / or assess Reasoning Models? Let’s start with the design implications and then we’ll move over to measurement.

Reasoning Q & A

First, let’s ask some additional, relevant questions in relation to AI Reasoning:

1. Is a Reasoning Model a singular architecture or a composite architecture (or could it be both)? - or does that even matter?

2. Does Reasoning require continuity of thought? (I’ll explain that in a minute)

3. Does Reasoning include Intuition and if so why? and how? (btw- as you can see, I included it in my definition above).

4. Does achieving something that we define as ‘Reasoning’ finally bring us to AGI? (and is it a precursor to any type of Super-intelligence?)

5. What does Reasoning actually give us with AI that it doesn’t already have?

(my) Answers…

1. I think it can be both, but may be ‘composite’ at first. It likely matters due to the efficiency question, with a singular architecture probably being more efficient in the long run.

2. I think so. “Continuity of Thought” refers to the ability to conduct Reasoning asynchronously over time (like humans do). This has architectural implications that go beyond accessing memory - this implies the ability to keep a process running in the background or in a cache and enhancing / adding to it over time.

3. Yes. Intuition as it relates to AI is going to be very complicated, so I’m dedicating a separate article to that (we’ll make it part 3).

4. Maybe. If it’s not, it may be close enough so it doesn’t actually matter.

5. Well, it appears as though I’ve asked myself a loaded question here. In part one of the series, I merely acknowledged that most experts think that we’re missing this capability with current AI. But what does Reasoning actually bring to the table? My take on this, is that it brings us a little closer to explicable AI processes (under the hood) and that’ll come from aligning them closer to the way we actually go about solving problems (which on the face it at least, seems to be different from how GenAI is doing it now).

Reasoning and Design

With the above Q & A as a backdrop, let’s look at this in two timeframes; near-term and long-term. BTW - parts 4 and 5 of this will take us a little further down the road at looking at these architectural options. (I’m sorry I can’t help it, I’m architect).

Near-term: I think that near-term, the way we get to a Reasoning Architecture, (note, I didn’t say “Model”), is to split out capabilities across multiple dedicated models (components) and somehow bring it all back together within the context of discreet problem-based processes. This is a little bit of a cheat of course, but it’s also the direction things are currently headed anyway for obvious reasons, including;

1. It allows us to bring more processing power to bear.

2. It allows us to focus on component capabilities with targeted models (plural).

3. It begins to get us working towards the ‘controller’ component which takes a closer to what might be thought of as an AI “Self.”

The downside here of course, which parallels what’s happening with Agentic Architecture, is that it’s not very efficient. Thus, while we may get the desired result, it may cost us much more than it’s actually worth.

Long-term: The obvious next step is somehow putting all of the components into a single architecture. While some may interpret this as single chip, I tend to think that this may be pushing things a bit too far (but you never know). And there’s several variations as to what a “Single Architecture” actually represents - we’ll look at that in greater depth in part 5 of this series.

Reasoning and Evaluation

One thing to point out first here, is that there are already a number of decent AI metrics floating around out that can be re-used or otherwise applied to assess Reasoning capability if included within a larger set (of measures) or context. This may already make up more than half of what we’ll need, so what’s the other half that may be missing? I believe that those measures include the following:

1. Intuitive problem-solving (again, I’ll address that in part 3).

2. Continuity (evolution of thought across iterations).

3. Rationale - this wasn’t mentioned per say in the definition above, but what I mean by this is the ability (if necessary and if feasible) to ‘trace’ or ‘track’ a decision making process in or across the models (making them ‘scrutable’). This in turn can be applied to the analyses of alternatives and the application of the other factors (which was listed in the definition).

4. And the most subjective and perhaps most important measure will be how successful a particular Reasoning solution (for any given problem) happens to be. I will tackle this measure in part 6 of this article series.

In our next article, we’ll take a deeper dive into how Reasoning and Intuition are related and also perhaps some further discussion about Continuity.

Copyright 2025, Digital Perspectives

Reasoning - the action of thinking about something in a logical, sensible way. (wow, that’s too vague, let’s try…) thinking in which logical processes of an inductive or deductive character are used to draw conclusions from facts or premises. (There yet? maybe not, how about…) Reasoning involves using more-or-less rational processes of thinking and cognition to extrapolate from one’s existing knowledge to generate new knowledge, and involves the use of one’s intellect. The field of logic studies the ways in which humans can use formal reasoning to produce logically valid arguments and true conclusions.^[5] Reasoning may be subdivided into forms of logical reasoning, such as deductive reasoning, inductive reasoning, and abductive reasoning.

That last one is from Wikipedia. So, we go from incredibly abstract and completely ambiguous to the Kitchen Sink approach. But, I think even here at the top-level we’re probably missing the mark with a lot of a priori assumptions and recursive definition (using the same thing to define itself). I think one thing in particular is probably way off here - and that’s the idea that Formal Logic is at the heart of things. Let’s take a look at that for a moment.

Most people have never studied formal logic and don’t know what most of those terms mean. Well, they don’t need to you say, because those terms simply describe natural processes, though. But the thing is, they don’t. Here’s an example from the Deductive Logic definition (also on Wikipedia):

Deductive reasoning is the process of drawing valid inferences. An inference is valid if its conclusion follows logically from its premises, meaning that it is impossible for the premises to be true and the conclusion to be false. For example, the inference from the premises “all men are mortal” and “Socrates is a man” to the conclusion “Socrates is mortal” is deductively valid.

There are lot’s of folks who wouldn’t necessarily apply this type of logic (knowingly and perhaps even unknowingly) and of course this the most basic example of the various types of formal logic being referred to. This isn’t knocking those people or formal logic per se, it’s merely a recognition that the everyday process of Reasoning likely doesn’t involve what we’ve defined as formal logic in most cases - and that makes sense given that humans have been Reasoning for 100’s of thousands and perhaps millions of years, but this type of formal logic didn’t actually get defined until about 2000 years ago. The thing that we’re trying to get at is the basic, underlying capability, not its formalization and synthesis into higher and perhaps more abstract representations. Now let’s look at AGI (I wrote an article on this last year); some have tried to encapsulate it as one definition and others have presented it as a set of levels (something I agree with)…

AGI (Artificial General Intelligence) refers to a theoretical form of AI that possesses human-like cognitive abilities, capable of understanding, learning, and applying knowledge across a wide range of tasks, unlike narrow AI, which is specialized for specific functions. An AGI system would exhibit abstract thinking, common sense, creativity, and the ability to sense and act in the world, matching the general intelligence of a human being. Wikipedia

Interestingly, this generic definition from Wikipedia fails to include Reasoning which perhaps just goes to show that the industry views on what AGI and Super-intelligence are is simply all over the map right now.

A New Top-Level Definition for Reasoning

In order for us to get to the point where we can quantify what Reasoning means in a measurable way, we’ll probably need a more pragmatic top-level definition. In order for the definition to work (in terms of supporting a more accurate and measurable definition of AGI) the new definition for Reasoning will need to have the following characteristics:

1. It cannot be defined recursively (e.g. using synonyms of itself in the definition).

2. It must declare the key component elements of the concept. It’s also important to recognize here that the concept is in itself - a process (in other words, an action or set of actions more than it is a thing - verb vs noun).

3. It must also include within each of those components some measurable or quantifiable elements. And those components should necessarily be dynamic (e.g. capable of change).

4. It must be generic enough to apply to both human and computational (e.g. Artificial) Reasoning.

5. It must also likely acknowledge in some fashion that Reasoning can occur in various ways and at various levels, (and that there is necessarily a Threshold or Thresholds associated with the various levels).

In other words, this definition can be neither abstract, nor all over the map - it needs to be constructed carefully in order that any system being designed to achieve it can thus conform with a set of concrete expectations. Well, that’s a lot. Let’s give it a try…

Reasoning (New Definition) - The related set of processes wherein a human or non-human intelligence is able to identify and resolve specific problems or challenges using a variety of dynamic techniques or capabilities. Reasoning typically involves the following components in helping to solve any given problem: a) pattern identification, b) analyses of alternatives, c) application of learned experience (intuition), d) application of learned knowledge, and e) application of learned behaviors. And Reasoning can occur at multiple intensities (depths and levels) and across various durations (instant versus extended, etc.).

Now that we’ve got this new definition, in my next article I’m going to address how we can; 1) apply it to AI or AGI design and 2) Measure it.

Copyright 2025, Digital Perspectives

Subscribe now

Note - This article was originally published in 2014, but still remains valid today…

There are still quite a few misconceptions in regards to IT Architecture. For many, hearing the term "Architecture" in relation to any IT topic seems to imply Enterprise Architecture (EA). To others, the notion of formal design processes represents the anti-thesis of Agile or responsive problem-solving. These misconceptions are unfortunate because there has never been more architecture connected to IT in actual practice and there has never been so much need for it.

So, let's start at the top - IT Architecture is a continuum and an umbrella for every design process in the enterprise. IT Architecture is the foundation for understanding every enterprise capability as well as being the starting point for all planning and governance. The reason it serves all these roles is because it provides the necessary insight for guiding all of those processes. Without that insight, making decisions and governing IT management or evolution becomes more or less like guesswork.

Why should this be so? Well, it has a lot to do with the disruptive and dynamic nature of Information Technology; it is not all uncommon for large organizations to have incomplete information in regards to their own systems, costs and data. Often times there are redundant, distributed islands of IT that cross business units or may even involve the separation of capability across IT & business communities. Gaining a complete picture of what's going in many organizations is quite a challenge - but is absolutely necessary in order to unify systems operation and to move forward in a coordinated fashion to exploit new opportunities and technologies.

So, let's go back and address those two very common misunderstandings again…

1 - IT Architecture and EA are the same thing (and EA is useless) - now I've paraphrased some of the criticism I've heard over the years about EA, but of course there is a legitimate question there. Is there any real value to EA? First off, EA and IT Architecture are not the same. EA is a top level architecture process and represents perhaps 20% of the total architecture that occurs in the typical enterprise. EA is integrated with IT Strategy and portfolio planning and governance.

Does EA have value? Yes, it does. It represents that portion of IT architecture that helps allow business stakeholders understand their IT capability landscape. It is high level enough to function as a communications tool, a governance framework and a project estimation bench-marking tool. EA is also, when done properly, the bridge to all other solution architecture.

2 - Does Architecture inhibit Agility? This is a thorny question and a complex topic, but I will try to address it briefly. At first blush, it might appear that any formalized design process might not fit within the context of the Agile Manifesto. But there are some important considerations worth noting that tend to contradict that initial assumption:

• Agile, as a methodology, has never been effectively transferred from a system or application scope to an enterprise scope except through the adoption of more iterative, time-boxed approaches to lifecycle management. There is a good reason for this - purist Agile approaches are focused on deriving requirements through experimentation rather than up front design.

• When you move from the application development scope to the enterprise integration domain things change - a lot. The problem at this level is no longer invention, but reconciliation and complexity management. In this context, the discovery associated with design relates to existing capability and introduction of well-defined new technologies. Here, IT Architecture provides the reference point for establishing and maintaining control over what otherwise might become a chaotic environment.

• Agile is all about making the application work by any means necessary - operations is all about making the enterprise work as a whole in the most efficient manner possible.

• And even within Agile, there is a design process and that process is merely one specifically-tailored component of a larger family of IT Architecture practice.

Perceptions are often hard to change and IT Architecture is a large, emerging and complicated field of practice. After working as an architect for 16 years, I can honestly say I've never seen more organizations doing architecture work. More often than not that architecture has become an important part of their overall IT management strategy. Yet, the continued misconceptions tend to hold back the true potential of IT Architecture. Too often, people view it from the perspective of one of the many sub-disciplines (such as Agile design, etc.) rather than seeing it as a holistic enterprise resource. I think that as the realization of its true scope becomes clearer IT Architecture will become even more important in the years to come.

copyright 2014, Stephen Lahanas