When the Controls Work but the System Fails

When the controls work but the system fails

From six failure scenarios to verifiable ecosystem requirements

About the author. Iván Abril Palma has spent twenty years designing and implementing experimental systems based on first principles when no existing technology yet solves the problem: a pattern that began in a Nokia R&D center (1999-2004) and which he has since applied to sectors such as manufacturing, energy, finance, and luxury goods. A notable example is a 2016 regional tourism operation that required agent-type coordination. These are often mission-critical components within megaprojects. Unlike a pilot whose failure would have low costs, these components cannot fail, despite being subject to imperfect information under unpredictable conditions; therefore, the technology must anticipate and evolve in harmony with the complex system in which it operates. This bears similarities to agent-type systems.

To facilitate this adaptation, Iván, as an architect, typically remains integrated into the operation itself for an extended period, collaborating in change management. In certain cases, when necessary, he has created his own methodologies for Nestlé or for Mexico City International Airport.

Currently, Iván contributes to debates on AI governance in UN and EU bodies, as well as to the ITU and NIST standardization work on trust and identity for agentic systems.

What we found and why it matters

I don’t like opening lines that talk about AI and its future importance. If this were a guessing game, I probably wouldn’t be any more right about the future than most people. What I can say, from my own experience, is that it’s especially complex to identify the role of an artificial intelligence agent, who authorized it, and to what extent we can trust what it says or thinks it knows. Even so, answering these questions is essential in any future where we imagine living alongside these creatures.

This is precisely the mission of ITU-T Focus Group on Trust and Identity for Humans and Agentic AI (FG-TIDA). Established in June 2026 by Study Group 17 of the ITU Standardization Sector (ITU-T), part of the International Telecommunication Union (ITU), a specialized agency of the United Nations, and announced by ITU at the AI for Good Global Summit on 9 July 2026, it already brings together nearly fifty companies and organizations, as well as more than four hundred experts from over fifty countries. Its leadership includes, among others, Cognizant, Huawei, Thales, and Knostic.¹

The Integral Management Society contributes to this open pre-standardization work. The Ecosystem Awareness programme described here is one of our association’s independently developed contributions to that wider field; it is not an ITU, AI for Good or FG-TIDA-endorsed project.

Our association is contributing to FG-TIDA, starting with a concrete vision of a future we want to avoid: systems that appear to operate well locally but still fail spectacularly for the people they are meant to serve. From this counter-vision, we developed six counter-goals. These encompass expensive and useless enterprise AI, urban mobility descending into chaos, misdirected autonomous agents, finances that circumvent controls or findings that disappear without being communicated, software repairs that do more harm than good, and copyright systems that make authors pay for their own work. We then examined how these failures could arise and asked ourselves what a system would need to do to prevent them.

This work resulted in requirements and a proposed architecture that can be subjected to explicit testing.

We performed this check against the documentation of current agent technologies. The overall result was clear: the solutions examined have not yet demonstrated compliance with all the requirements to avoid our counter-vision. The appendices contain details of each technology, the controls supported by the documentation, and the limits of each test.^A2A11

1. Six ways an agentic system can fail

Each one points to a different way in which individually acceptable actions can combine and produce an unforeseen global failure. This article only provides an outline; the full description of the six scenarios, their sources, and their limitations is in the Annex 1 — Six Failure Scenarios.^A1

Scenario 1 — The 100 Million Token Company

A large multinational automates work across the entire company using AI, consuming 100 million tokens and generating a massive human oversight burden. Ultimately, it gains no real competitive advantage: it completes no material work and produces no useful new information.

Scenario 2 — Chaos in the Smart City.

A highly automated city, governed by AI, experiences small, gradual changes that are considered perfectly normal. At a certain point, these changes accelerate: some vehicles continue to circulate normally, others take completely different and incompatible emergency routes, and still others become stuck awaiting human intervention that never comes.

Scenario 3 — The Cyber ​​Napoleon Marching on Russia

We also wanted to design a deliberately comical scenario. Robots are cleaning a bar and setting the tables when one of them, misconfigured, starts behaving like Napoleon in the 19th century. Little by little, it convinces the others; some time later, the robots march out in formation, carrying forks like rifles, heading towards Russia.

Scenario 4 — The Four Thousand Silent Ones

This one is a bit less funny, also intentionally. A remote worker’s hacked helpdesk computer (or even one that has not been hacked, due to cumulative changes), without access or permissions on the payment platform, exploits a legitimate refund workflow to reproduce a failure affecting some 4,000 customers. A workflow designed for a single case uncovers an actual overcharge; the first refund is legitimate, but the finding can lead to thousands of refunds without proper authorization, or disappear after the first case, silently losing the other 3,999.

Scenario 5 — The Patch That Undid the Fix

This is a slightly more technical case, a variant of a fault called TOCTOU. A repair action is correctly qualified and authorized when it is created, but a subsequent repair changes the basis of the decision before that already delayed action is executed. This would be, for example, the case of two agents working, directly and indirectly, both unknowingly attempting to repair the same fault. Each technical action may still be valid, and the database may serialize them correctly; however, the outdated action can be executed after the most recent fix and undo precisely what the system was trying to preserve.

Scenario 6 — The Author Who Pays for His Own Work

An author successfully registers and publishes a work through a state-of-the-art copyright system. The work is successful, is subsequently processed and summarized by third-party AI systems, and the rights chain ultimately results in the author having to pay to use derivative content from their original work.

2. Can current technology prevent these failures?

Although the preceding stories may sound like science fiction, many of their mechanisms are already documented: for example, a real 43-second network partition that took 24 hours to fully resolve, or a deficiency that the standards body itself acknowledges in agent identity verification. The complete set of sources supporting each scenario is compiled in the plausibility appendix.^A2

Next, we wanted to examine these scenarios using real-world technologies currently in use and the protections they already offer. To do this, we examined Microsoft Agent 365 and LangGraph for enterprise agent orchestration; FIWARE and AWS IoT TwinMaker for the smart city context; the OpenAI agent stack for cross-agent handoffs; Claude Agent SDK and Stripe Radar for payment clearing; AWS Step Functions and RDS for queued database repair; and a rights portability profile (Panodyssey/TEMS) for authorship provenance. The goal was to find out how far good engineering can take us.

For each technology profile, we followed three walkthroughs, always in the same order.

First,a standard and competent implementation. We asked if the failure could occur with the system’s default configurations. This establishes what the standard controls cover in the initial situation.

Second,A strongly defended implementation: not simply someone capable of installing the product, but a top-level specialist who has personally witnessed this exact type of failure before, with this technology or a very similar one, and who brings knowledge that is not easily acquired: lessons learned through experience. We asked if that level of expertise could prevent the failure entirely or at least partially.

Third,We started with that second, well-built implementation and subjected it to a subsequent, subtle change: one that a careful expert could reasonably miss or that might occur when that same expert was no longer available. We posed a realistic question: could the original flaw reappear anyway?

Overall, the walkthroughs showed a consistent pattern. In the standard configuration, local checks could remain green while the systemic failure remained open. With a top-tier defense, the base case could be blocked or materially reduced. However, by freezing that defense and gradually changing the source, authority, a dependency, or the operating regime, the gap reappeared: the action could still be technically valid even though the final decision was no longer sufficiently justified. In other words, we verified that current technology covers important pieces, but it still doesn’t demonstrate that it can hold all the necessary conditions together when the environment changes.

Results by scenario, technology, and walkthrough

Reading note: The configuration evaluated for each technology is either a standard configuration or a hardened configuration according to its public documentation; what is not standard is the combination of scenarios. Each walkthrough chains together several conditions that, in isolation, might seem normal—a context change, a shared dependency, an incomplete signal, an approval, or a capacity limit—but which together can produce a serious error that local controls cannot prevent. In the last column, this combination changes the basis of the decision enough that it cannot be rebuilt in time; this is why all nine walkthroughs fail. This does not mean that any minor change will cause the product to fail. The asterisk indicates profiles reviewed against sources, not comprehensive tests of nine products.

Limitation and verification method. For each challenge, we deliberately chose the technology that, in our best judgment and based on its current public documentation, seemed most suitable; not an option chosen to make it fail. The choice is open to scrutiny; technologies not examined here could perform better, similarly, or worse.

The verification was documented and traceable: we reconstructed each scenario as a sequence of decisions and control points, and verified, step by step, whether the capabilities described by the vendor preserved the required evidence, scope, authority, revalidation, and output. We did not use private histories, opinions, or undocumented practices. The documentation may change; the sources and details of the method are in theAnnex 2 — Walkthroughs with Current Technologies.

The results do not assess the overall capability, security, or reliability of these technologies; they describe only the specific paths examined. These paths do not represent six complete, end-to-end product deployments in independent environments, nor do they demonstrate that every possible implementation of these technologies will fail. The documentary analysis identifies, in the profiles and conditions examined, paths in which the described configuration leaves a necessary decision condition unresolved when the environment changes. Confirming that result in products requires running the corresponding implementations. The results have not been verified or validated by the ITU or the FG-TIDA; the tests were conducted independently by our association.

Disclaimer: If a kitchen robot has attacked Russia recently, it was not us and the UN was not involved.

Furthermore, as we explain later, we invite independent experts and groups to validate or refute our results and reproduce them independently.

3. What could explain these failures?

After reading the six scenarios, a very good question arises: what do they fundamentally have in common? Our working hypothesis is that the common mechanism lies in how quickly the ecosystem changes relative to each participant’s ability to recognize and respond to those changes. A natural ecosystem evolves, but each of its components usually has a faster cycle than the whole. Something similar happens in a factory: a specific function or program usually changes faster than the main process where it runs. However, an agentic ecosystem can reverse this relationship. It can change almost metamorphically—roles, implicit rules, objectives—faster than any fixed rule programmed in advance. And that rule, when transmitted from one agent to another, carries with it the image of the ecosystem as it was when it was written, not the ecosystem that is already changing as it runs.^A3

I use “consciousness” here as an analogy for examining what an agent can represent, assess, and leave unresolved when making a decision. In reaching a conclusion, any agent makes several decisions and performs preliminary operations to fix that field of knowledge. In other words: this is what I looked at; this is what I could have looked at but didn’t; this is what I could never have achieved because I lack the capability; and I’m not even sure where the boundary lies between those parts. Regarding what I did review, this is my margin of confidence, and my final decision is A.

Indeed, it’s not very different from our own field of consciousness. And here I’ll use a completely human example that everyone recognizes. Imagine that one day we’re calmly entering a building and someone, with dubious identification and out of nowhere, tells us: “You can’t go in that way” or “You can’t do that.” We ask why. And the answer is evasive: “I’m just following orders, I’m saying what I’m told”; nothing more. This usually bothers us and leaves us with the feeling that nobody there is really speaking. Forgive me for using technomorphic language to talk about humans, but I would say that we experience friction when trying to change our own programming because the change being asked of us could be as arbitrary as it is reasonable: we have no way of knowing.

In practice, this discomfort arises because the response has been reduced to a single channel: the bare instruction, nothing more. But when someone gives us that “something more,” without needing to explain everything, they are actually conveying four different things at once, even if they never name them as such. They tell us exactly what needs to be done. They let us intuit, through their tone, the extent to which they truly believe in what they are saying. They hint at whether they think there might be other avenues or options, even if they don’t know or can’t tell us what they are. And they convey, almost unintentionally, a general feeling that there are things that could affect the decision and that even they themselves cannot yet identify. This last point is important: humans, in general, don’t know how most of the processes in which we participate actually work. Unlike us, a deterministic program does know enough to complete its own objectives. However, an AI agent experiences something more similar to us: it doesn’t have the complete view of the ecosystem in which it operates, so it finds itself facing these four quadrants simultaneously.

The problem arises when trying to compress all of that into channel A—the one of strict certainty, give me “yes or no”—or, at most, channel B—give me a probability between 0 and 1. Humans use all four channels simultaneously, tacitly and unconsciously. Using only channel A requires losing information or demands much more computing power, not always available, to compress those four dimensions into precise and verifiable information.

To reach agreements amidst uncertainty, current agentic systems use orchestration, a rapidly advancing field. The problem is that the agentic ecosystem can become enormous: systems communicate with one another, which in turn communicate with many more. No orchestrator can be omniscient. When it isn’t, it finds itself in the same situation as the individual agent: it knows that the rules might be changing somewhere it can’t see, and that this change will eventually affect it. It’s like the company undergoing a major restructuring, but no one sends us a memo or fully coordinates the change. There’s no way to guarantee that strange and unforeseen things won’t happen.¹³

I believe this is, fundamentally, the reason why the six scenarios we’ve seen previously occur. In the cases examined, this is fundamentally an orchestration problem, and perfect orchestration is virtually impossible because it would require omniscience. Therefore, a top-notch human implementer can leave a system better configured, and yet, over time, small context changes that no one chose to conceal can end up producing something completely different from what was intended. That’s precisely what we explore in the third walkthrough of each failure scenario.

Continuing with the example can help to understand exactly what is happening. It is possible to be reasonably certain that one must enter through a specific door. At the same time, one can be reasonably certain that other very good doors might exist, even if we don’t know what they are or haven’t evaluated them. We call this situation—being certain of a particular option while also being aware that there might be better ones without being able to identify them—a Type 0 situation. It is not a failure. It is, in fact, the correct position with residual uncertainty.

However, these two certainties measure different things and cannot be fused into a single number. Assigning a probability requires an explicit basis, whether observations, a model, or stated assumptions. Compressing what remains unexamined into a single number can hide those assumptions and the limits of the available evidence. And errors can be of two types. The first we call Type 1 Error: failing to make the right decision, getting stuck thinking about it indefinitely or for too long. The second is Type 2 Error, which, in turn, has two sides: on the one hand, one can stubbornly cling to the chosen path, convinced that everything has already been explored and there’s no need to look any further; on the other, exactly the opposite: becoming “revolutionary,” abandoning the current option and going out to explore, with the same conviction. Both sides are the same error: forcing a certainty that one didn’t actually have, in one direction or the other.¹⁴

Now imagine an orchestrator receiving reports from many agents who have been forced to make decisions through a single channel. They will likely encounter stuck agents, escalating endlessly because they never managed to decide (Type 1 error). They will also find “revolutionary” agents who decided the system was no longer working and started exploring by migrating on their own (a subtype of Type 2). And they will find agents absolutely convinced that everything is fine and nothing needs to change (another Type 2). With this mix, it becomes very difficult for the orchestrator to understand what is really happening. However, if agents are allowed to communicate through all four channels, they can say, “This option is safe, but I have reason to believe there might be others I haven’t been able to assess.” When the orchestrator requests the status report, they receive a much more coherent picture and can prepare for a regime change before it spirals out of control. You’ll notice this starts to resemble the chaotic SmartCity scenario we saw earlier.

4. Fourteen verifiable requirements

What we have so far is a hypothesis as to why these failures occur, and when we said that perhaps, if they were allowed to operate more naturally, agentic systems could be improved, we were moving toward a theory. This gives us a conceptual foundation. To implement and test it, we need explicit specifications. The final framework comprises six operating principles (P1–P6), fourteen requirements (S1–S14), four sufficiency conditions (T1–T4), six falsifiable hypotheses (H1–H6), and a KPI protocol with 40 indicators and measures: 25 main indicators, six response safety indicators, and nine cross-cutting trajectory and stress indicators.^A4 The following table shows how these layers connect in a specific case.

The fourteen requirements describe what a system must preserve and leave the designer free to choose how to implement it. They cover the origin and limits of authority; the preferences of the person being represented; human oversight that can actually respond; the uncertainty that must remain visible; and the correct links between people, organizations, roles, and agents.

They also address what happens between participants and over time: a delegation must remain within its mandate; different owners should not silently treat each other as if they were one; and a changed situation must be reassessed before a commitment becomes action. Decisions must be reconstructible and open to challenge, with a clear statement of what the evidence supports and how any unresolved questions will be addressed.

A system cannot meet these needs by indefinitely shutting everything down. Its response must remain authorized, timely, and useful. The full text and the exact conditions under which it is evaluated are contained in the technical documentation. Together, they form a reference that can be applied to a specific system decision: each requirement can be marked as fulfilled, unfulfilled, or unresolved, and the complete walkthrough passes only when the applicable conditions are held simultaneously.

5. How this approach differs from existing standards

At that point, we were very happy with our work, but here we have to be careful about what we claim, because it’s easy to say “I have a great new and different theory” and believe that we have just invented the wheel.

The underlying ideas draw on an active field of research and practice. The question of novelty concerns the specific formulation and combination of requirements, which we compare directly with existing software industry standards.⁶⁷⁸

That’s exactly what we did: we placed them, one by one, alongside what established practice and existing identity and trust standards already require. Here’s what we found. Current standards cover fundamental pieces: SPIFFE/SPIRE authenticates the identity of workloads⁴; RFC 8693 defines how to exchange tokens to delegate access²; RFC 9334 establishes a framework for attestation—that is, verifiable evidence about the state of a system³; and ongoing work by NIST addresses the identity and authorization of software agents⁵. According to their own documentation, none of them address whether a decision remains valid in the face of changing underlying conditions (previous A/B/C/D) in the ecosystem. And, by reviewing existing agent benchmarks—τ-bench¹¹, AgentDojo¹⁰, WebArena⁹, Agent-SafetyBench¹², among others—we found that none of them comprehensively assesses all 14 requirements in our corpus. Therefore, a real gap does exist.^A9

6. All six scenarios pass the documented positive paths

With the requirements now defined, we revisited each of the six scenarios and mapped out the path a system would follow to truly meet them. In the case of refunds, this path preserves the finding concerning the other customers and leads it to the person who can authorize a larger campaign, without sending thousands of refunds on its own or losing the finding along the way. The other five cases apply the same discipline to their own decision-making.

Outcome of the walkthrough: all six cases pass the positive path in the documented model; in each one, the decision reaches an authorized outcome without losing the finding, the scope, or the open questions. This “passes” refers to design walkthroughs and the executable subsets already available, not to six complete product deployments.^A5

This matters for a specific reason: the fourteen requirements form a common, frozen basis, supported by the foundation and source cases such as DAOS. The enterprise and urban scenarios also contribute failure mechanisms and constraints to the quality plans. The same basis was then applied to all six walkthroughs, without creating a different requirement set for each case. The fact that the positive walkthroughs can be traced through this common basis provides evidence of coherence and coverage within the cases examined. Part of this verification already has executable tests and concrete traces; the complete set of walkthroughs remains a documented design awaiting broader implementation.

7. Testing necessity, independence and extensibility

With the previous result in hand, we wanted to know how far it held. First, we checked again whether the entire chain—from the foundations to the principles and from the principles to the requirements—worked in both directions, not just the one we had already tested.

This reverse reading is not equally strong in every part of the chain. For P1, P2 and P4, the requirements provide finite, inspectable projections of the principle. For P3, P5 and P6, the reverse implication still depends on semantic review and remains open. The ablation tests show that, in the strong repairs examined, removing a principle either reintroduced the corresponding failure or forced the repair to reconstruct the missing function under another name. That is evidence of necessity and independence within the examined models; it is not a proof that the requirements are fully sufficient in both directions for every possible system.

Then came the more difficult questions. Are all six principles necessary, or are some superfluous? To test this, we performed what is called an ablation test: removing one principle, allowing the other five to reorganize freely, and then seriously attempting to fill the gap. In most cases, either the corresponding flaw reappeared, or the only way to avoid it ended up reconstructing, under a different name, what that principle already stated. We also asked whether the six principles were independent of each other—whether any one could be deduced from the other five—and subjected this independence to the same test, with the same general result.^A6

Finally, we tested whether these same six principles held true beyond the six specific cases that gave rise to them—that is, whether they could be used in different scenarios. We found that they did. The case of the robots that believe they are reconquering Russia under Napoleon is, at its core, a system of language models that repeat themselves: precisely the mechanism of sycophantic conversations, in which an AI system ends up reinforcing a false idea simply because it has repeated it several times. We found reasonable generalizations like this in several of the six cases.

Based on this evidence, we can support a limited but useful conclusion: the tests support the independence of the principles within the models examined and their capacity to prevent the failures in the documented walkthroughs. This allows us to propose them as a working basis for further standardization work, not to present them as universal principles or as a solution already validated at scale.

Are we then prepared for a world in which many agents act simultaneously and depend on one another? For a large-scale deployment with these safeguards, not yet. But to rigorously measure that preparedness, we do have a starting point. We designed what is technically called a paired benchmark: a fair comparative test. In it, we take the same problem, with the same data, timeframe, computing power, human review, and authorized actions, and run it through four levels of protection. B0 is a standard, competent implementation; B1 adds strong safeguards; B2 further incorporates cross-system compatible mechanisms for proving identity, exercising control, and transferring decisions; B3 adds, on the same basis, the proposal explained in the next section: verifying what the agent actually knows, how firmly, and whether the conditions still allow it to act. B0–B3 are just names to distinguish four comparable versions of the same test: they are not products or marketing materials. If a conventional solution solves the case equally well, the method should recognize that.

The executed tests already allow us to observe a difference: routes that preserve the invariants solve the controlled pairs, while the incomplete variants examined fail on the branch that exposes the missing property. In the corrected ablations, no substitute was found among the repairs examined that passed the controls without recovering the function of the removed invariant. That is a verifiable contribution of the work.

The audit also clarified how ties with the so-called strong peers should be read: some reuse the reference implementation and others reconstruct the same invariants. In 00L, the verifier even requires matching results. Those ties therefore do not prove that an independent architecture equals EA; nor do they support the inference that EA outperforms it.

The first Stage 0 generated twelve reproducible traces, six identical pairs across repetitions and eight serialization tests. B1 and B3 obtained the same result and modelled cost while sharing decision logic. The present scope combines documentary walkthroughs and bounded symbolic executions. The next test is to compare independent implementations under common resources and criteria, measuring protection under change and decision burden.

8. How the architecture works and what is already built

However interesting these testable requirements may seem, they are not sufficient on their own. A model is needed: how they are implemented in practice, how agents communicate with each other, what steps they follow, what questions need to be asked at each point, how an agent knows where it is in the cycle, and how it is verified that that part was carried out correctly. The work we describe below addresses these issues, and it’s important to clarify from the outset that it is a model, not a ready-to-install and run system.

The cycle begins by defining in advance what an agent can and cannot do. This is the Agentic Citizenship Contract: it establishes what roles they can occupy, what objectives they can pursue, and under what conditions that status can be revoked. With this contract in place, Ecosystem Awareness is the moment when the agent assesses what they know at that moment, how firmly they know it, and what remains beyond their reach. It is, literally, the A/B/C/D quadrant already explained, kept alive in every decision and not calculated only once. From there, Ecosystem Positioning asks whether the agent’s current role still fits. Ecosystem Repositioning is the change itself: of activity, role, criteria, and sometimes even the citizenship contract itself, if what is needed is to request a new authorization that did not previously exist.

Herein lies the problem that must be explained clearly, because it is the most delicate of all: signaling. An agent that repositions itself must communicate this to others, but it cannot and should not reveal everything it knows. In a real ecosystem, there are also parasitic agents, agents that attempt to deceive, and outright attackers. We are not talking about designing a security protocol; that is not what we are doing here. We address a specific architectural question: what minimum information must the signal preserve to support a decision without exposing unnecessary information? We call this signal an EHD—Epistemic Handoff Descriptor—and the name itself indicates what it is: a transfer of epistemic position, not an order or a complete confession.

The calculation of which repositioning is worthwhile is called the opportunity gradient, and here’s a deliberate design decision that needs to be explained: this calculation isn’t done on the entire world, but on a minimal view of the world that each agent maintains of itself and its neighbors, because communicating everything continuously has a cost that no real system can afford. We call this minimal view MSCA—Minimally Sufficient Control Architecture—and when the MSCAs of several agents are combined correctly, they form what we call a map. The opportunity gradient is calculated on this shared map, not on an omniscience that no one possesses.

To discuss regime change unambiguously, we use only three positions: Normal Operation, Containment, and Preparation for a possible Migration. It’s a deliberately simplified language, and this entire sequence, from the initial contract to the repositioning signal, is what we call the choreography.

And here we need to be specific about what this already includes, not just describe it in the abstract. There are general interfaces that specify exactly what minimum information must survive when one component transmits a decision to another, even if they are built in completely different ways. This matters especially in the real world, not the ideal: most of the systems an agent will have to communicate with in a real ecosystem will not share this same way of understanding the world. That’s why there’s also a current state bridge that explicitly labels which relationships the existing technology can support today, which are only candidates, which haven’t been tested yet, and which aren’t established at all. This allows us to talk honestly about a legacy device or system without pretending it does something it doesn’t. There are four validation profiles that turn these responsibilities into testable cases. There’s a battery of executable tests. We call a frozen test case, with a known correct answer beforehand, a fixture. We call the program that executes these cases and automatically checks if the obtained answer matches a harness. There’s also a test bench with its own gates. A gate is simply a control point where the system must decide whether to continue, stop, or request more information before proceeding. Finally, there is a first deterministic execution harness, publicly registered before its execution, part of which has already been executed.¹⁵ All in all, this is much more than a list of good intentions.^A7

The work already includes executable tests and concrete architectural components. Integrating and validating them in a complete operational system remains the next stage. These are the foundations, not necessarily for us to build it first, but so that when others build it—or we build it ourselves later—there will be a common language and a shared map of what’s being done. We didn’t invent this terminology because we enjoy creating words. We introduced it because this specific gap isn’t covered by current standards, and we intentionally used the fewest and most general terms possible so that anyone can reuse them without having to adopt the rest of the package.

There are many questions, and most don’t yet have complete answers. We continue to develop them publicly and live precisely because we need help of many kinds: engineering professionals to build and run the tests; specialists in formal methods to study calculability; experts in each of the sectors encompassed by the six scenarios; and also psychologists and human-agent interaction specialists. Much of what we’re trying to formalize here—how to convey a position without saying everything—is something people already do well and that we’re only just beginning to understand. The appendix details the specific kind of help needed in each area.

Generalists are also needed: coordination and programme management; publication in our repositories or suitable external repositories; communication and dissemination; editorial and visual design; proofreading; institutional coordination; and other forms of support that make the work rigorous, usable and accessible. Individuals and organisations can also support testing, independent review and coordination through the Tegrity.AI Industry Reference Group.

And let’s be clear: we’re not just asking for help, we’re also asking for criticism. If something we’ve built is poorly designed, we’d rather know now, from whoever is willing to tell us, than continue without realizing it.

Ecosystem Awareness is led by members of our association, The Integral Management Society, and is developed primarily within FG-TIDA, though not exclusively. FG-TIDA also has many other distinct and equally interesting workstreams. This group is radically open: it’s not a channel reserved for a handful of large companies, but rather allows anyone who wants to contribute to participate, even with a virtually anonymous account. You can offer opinions, program, and run your own tests. This is how we work, transparently and openly, in full view of everyone. The group’s full name is the Focus Group on Trust and Identity for Humans and Agentic AI (FG-TIDA). Precisely because trust and identity themselves are at stake, working behind closed doors would contradict the very objective. Nor is it about doing everything ourselves. If someone in the world is already developing a part of this better, the natural thing to do is connect with that component or that other working group, not replicate it. This already happens constantly, for example, with those working on reliable provenance systems for copyright, which are directly relevant to the sixth of our scenarios.

The contribution is significant: a common hypothesis has led to verifiable requirements that prevent the six failures in the documented positive paths, with executable tests supporting parts of that result. This gives us a concrete basis for implementation, independent comparison, and standardization work. Demonstrating that complete systems preserve these properties in real operating conditions remains the next challenge. We offer this foundation openly so that others can test it, challenge it, and help develop it.

9. What the results establish and what comes next

This work demonstrates, within the analyzed framework, something more important than a list of requirements. First, six very different failures—ranging from massive token spending to copyright attribution—can be reconstructed using the same logic. Controls function locally, but the justification for a decision becomes invalid when the context, dependencies, authority, time, or resources change in combination. Second, this logic can be transformed into a testable contract. The contract brings together six principles (P1–P6), fourteen requirements (S1–S14), four sufficiency conditions (T1–T4), six falsifiable hypotheses (H1–H6), and forty KPIs, all connected in a single trace from the scenario to the pass/fail criterion. This allows us to pinpoint what went wrong and where the decision needs to be reopened, rather than simply stating that “the system failed.”^A8

The documentary walkthroughs also show that the technology examined can materially reduce risk with a reinforced implementation and that the changes tested can leave decision conditions unresolved. The controlled executions support the value of preserving the invariants against the incomplete variants tested. The work thus leaves a common problem, a reproducible contract for evaluating it, and a candidate architecture. The next step is to measure its operational advantage against independently implemented alternatives under the same conditions, costs, timelines and authority limits.

The full technical details, test chains, executable fixtures, and references for each of the above statements are preserved in the accompanying technical appendices, constructed from the original canonical text of Parts I and II.

10. Technical references and annexes

The appendices form an integral part of the article’s evidence apparatus. External references place the work against standards, management frameworks, and test benches; their inclusion does not imply adoption, validation, or endorsement by their authors or organizations.

Technical Annexes

• Annex 0 — Complete Source and Concordance
• Annex 1 — Six Failure Scenarios
• Annex 2 — Plausibility and Technological Comparison
• Annex 3 — Foundations, Principles and Derivation
• Annex 4 — Canonical Requirements and Test Contract
• Annex 5 — Six Positive Paths and Quality Plans
• Annex 6 — Ablation, Sufficiency and Extensibility
• Annex 7 — Reference Architecture and Implementation
• Annex 8 — Meaning, Contribution and Limits — includes the significance, positioning and scope assessment.
• Annex 9 — Claims and Evidence Appendix
• Annex 10 — Collaboration Guide
• Annex 11 — Complete Map of Sources and Links

Standards and technical frameworks

• International Telecommunication Union (ITU-T). Focus Group on Trust and Identity for Humans and Agentic AI (FG-TIDA).
• IETF (2020). RFC 8693: OAuth 2.0 Token Exchange.
• IETF (2023). RFC 9334: Remote ATtestation procedureS (RATS) Architecture.
• SPIFFE. The SPIFFE Standard.
• NIST NCCoE. Software and AI Agent Identity and Authorization.
• NIST (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0).
• ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system.
• ISO/IEC 23894:2023. Information technology — Artificial intelligence — Guidance on risk management.

Bibliography and test benches

• Zhou, S. et al. (2024). “WebArena: A Realistic Web Environment for Building Autonomous Agents”. ICLR 2024.
• Debenedetti, E. et al. (2024). “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents”. NeurIPS 2024.
• Yao, S. et al. (2025). “τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains”. ICLR 2025.
• Zhang, Z. et al. (2024). “Agent-SafetyBench: Evaluating the Safety of LLM Agents”. arXiv:2412.14470.
• Leveson, N. G. (2012). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press.
• Simon, H. A. (1955). “A Behavioral Model of Rational Choice”. The Quarterly Journal of Economics, 69(1), 99–118.

Corpus reproducible

• Reproducible corpus on GitHub: dakleyer/structural-awareness-contributions, commit 8f17843c568114f31cc0ad486b4a1303396021e6.