בס״ד
Wonder Cohen logo

Roy Wonder Cohen · Sovereign Systems Architect

Building systems that survive contact with reality.

I design and operate sovereign Linux infrastructure, multi-agent AI environments and post-quantum security systems. This is where I publish what works, what fails and what it takes to make emerging technology dependable.

Read the latest field note Explore my work
Linux 🐧 DevOps & SRE Security Engineering Multi-Agent AI Post-Quantum Cryptography Executive Technical Advisory
// 01 - field notes

What I am learning in the field

A running journal about infrastructure, AI operations, security and the lessons that only become visible when systems leave the slide deck and meet the real world. New entries appear at the top.

Human–AI systems Cognitive Chain Management

The chain still needs to be managed.

I did not set out to develop a human–AI working method. I was building a startup and trying to manage a complex project with several specialised AI agents.

Cognitive Chain Management illustration showing a human Chain Manager coordinating technical, operational, strategic and governance specialists through evidence gates while comparing reported state with live operational reality.
Human intent, specialist work, evidence and live reality must remain connected. The chain is only as strong as its weakest verified link.

Each AI agent could produce useful work. But activity was not the same as readiness.

An agent could confidently report success while working from stale context. A component could pass a test while a lower-level dependency remained unverified. Two specialists could describe different realities because they had observed the system at different moments.

The real challenge was not simply using AI. It was managing the complete chain between human intent, specialised reasoning, technical evidence and the actual live situation.

From AI assistance to chain management

That experience led me to develop Cognitive Chain Management, or CCM: a working method for deciding whether a human–AI system is actually ready rather than merely active.

CCM treats the human as the Chain Manager, not as a passive approver. The Chain Manager defines intent, delegates within clear boundaries, translates between specialist domains, compares reported reality with live reality and retains final accountability.

  • Intent before execution: specialists receive the objective, purpose, constraints and decision boundaries.
  • Evidence before readiness: a confident report or successful task is not enough; the relevant evidence gate must be closed.
  • Scope before system claims: a ready component does not automatically make the complete system ready.
  • Reality before narrative: reported state must be checked against the live operational situation.
Operational rule: a higher-level demonstration cannot repair an unverified foundation. When assumptions change, evidence becomes stale or new scope enters, the relevant readiness gates reopen.

A combination of established practices

CCM does not claim that its underlying ideas are new. It combines established practices such as readiness levels, intent-led delegation, specialist depth, blameless learning and authoritative operational state into one repeatable human–AI operating method.

Its proposed contribution is the combination: continuous human chain management, translation between specialist domains, comparison of live and perceived reality, and one authoritative state for the complete operation.

A group of capable agents does not automatically become a reliable system.

The chain still needs to be managed.

How is your organisation deciding whether its human–AI workflow is actually ready, rather than merely active?

AI operations Context windows

The memory ceiling came back. This time, it fails quietly.

In 1990, crossing a memory limit stopped your program. In 2026, an AI conversation can cross its useful limit and keep running: fluent, confident and increasingly unreliable.

Pixel-art comparison of memory sizes from a kilobyte to a terabyte, with AI token ceilings represented as increasingly large containers of water.
Storage grew from glasses to lakes. AI conversations are still filled one message at a time.

The old limit was visible

The 640 KB barrier was brutal, but honest. When a DOS program ran out of conventional memory, it stopped. You received an error and knew exactly what had happened.

Modern AI fails differently. A long conversation may continue producing polished answers while losing earlier constraints, blending old and new instructions or paying too little attention to information buried deep in the session. The interface remains calm. The quality quietly drifts.

A context window is not a hard drive. It is a working attention budget.

Large ceilings still get consumed

One of my own AI operating packages begins with roughly 80 KB of reference material: agent behaviour, architecture, engineering rules and code-of-conduct constraints. That is around 20,000 tokens before the real work starts. Repeated context, corrections, answers and handovers consume even a very large ceiling faster than the headline number suggests.

We became used to memory being abundant. That instinct does not transfer cleanly to AI. Every instruction and every repeated block of reference material competes for attention inside the same working space.

The operating discipline is familiar

  • Keep durable instructions lean and remove repetition.
  • Separate verified state from disposable conversation history.
  • Use concise handovers and start a fresh session before drift becomes obvious.
Operational rule: treat context as a budget, not an infinite archive. A fluent answer is not proof that every earlier detail is still being handled correctly.

The technology changed. The discipline did not. We are rationing memory again; the new failure mode is simply quieter and easier to miss.

View the original LinkedIn post →
Multi-agent AI Governance

When two AI agents disagree, check the clock before the evidence.

Two agents reported opposite facts about the same server in the same hour. Both reports were accurate. The missing fact was not technical; it was chronological.

Observation one

The service was running when the first agent inspected it.

State changed

The service was manually stopped and started outside either agent's visibility.

Observation two

The service was down when the second agent inspected it.

The contradiction was real, but neither report was wrong

I operate a multi-agent AI environment while building post-quantum cryptography infrastructure. The agents have strict domains: one owns the operating-system layer, another owns the code. They do not share a live view of every action happening around them.

One agent reported that a service was running. Minutes later, another reported with equal confidence and equally valid evidence that the same service was down. My first instinct was to decide which agent had failed.

The right first question was not “Which agent is wrong?” It was “What changed between the observations?”

The service had been manually started and stopped four times in less than three hours. Each agent had captured an accurate snapshot of a different moment. The apparent credibility problem was actually a missing timeline.

The governance rule it forced me to write

Chronology before credibility: when two agents disagree about live state, compare observation times and identify state changes first. Only investigate agent reliability after a timing explanation has been ruled out.

That rule sounds obvious after the incident. Before the incident, it was not written anywhere. This is how real governance develops: a system exposes an ambiguity, and the operating model gains a rule that prevents the same ambiguity from consuming another day.

Orchestration is not the hard part

Connecting several agents and dividing responsibilities is the easy part. The difficult work begins when individually correct agents become collectively contradictory. Someone must define how evidence is reconciled, which facts take priority and when the system must stop and ask for a fresh observation.

Anyone moving from one AI assistant to a coordinated team will encounter this. Build disagreement handling into the operating model before the first contradiction arrives, not after it has already cost you hours of reconciliation.

This is a living journal. New entries are placed at the top.

// 02 - areas of work

From foundational infrastructure to emerging technology

My work sits where engineering depth, operational ownership and strategic decision-making meet. The common thread is simple: systems must remain understandable, defensible and operable after the presentation ends.

Sovereign Linux Infrastructure

Secure, resilient Linux platforms, automation and high-availability environments designed for organizations that need control over their own technology.

Multi-Agent AI Operations

Governed AI environments with clear agent boundaries, verified handovers and operational controls built from real use rather than architecture theory.

Post-Quantum Security

Hands-on development, consulting and lectures on quantum-era security, Q-Day readiness and practical post-quantum cryptography.

Executive Technical Advisory

Direct technical guidance for leaders making high-impact decisions about infrastructure, security, emerging technology and engineering capability.

// 03 - operator's perspective

Operator notes, not trend commentary

I have spent more than fifteen years building and operating Linux and infrastructure in enterprise and government environments, including high-security organizations. My work now extends that same discipline into multi-agent AI and post-quantum security.

I write from the operator's seat: verified state, real failure modes, trade-offs and the lessons that appear when a promising idea has to become a dependable system.

// 04 - speaking and advisory

Straight answers for technical leaders

Building and Running a Multi-Agent AI Environment

A practical talk for technical leaders deciding whether and how to put multi-agent AI into production. It covers a working environment, a documented governance failure and the operating protocol written in response: the operator's view rather than the vendor's.

Discuss a talk or advisory session

Reach me directly at roy@wondercohen.nl.