I am interested in autonomous systems, but I’m increasingly less interested in autonomy as a feature by itself.
The question I care about is:
What does a system need to prove before we give it permission to act?
APEX and Purple Guard are where I have been exploring that question.
APEX is an AI-native marketing system built around multiple specialised agents and a recurring operating loop.
Purple Guard sits underneath the AI systems as a governance layer for model access, policy and increasingly broader agentic controls.
My contribution
I have designed and operated the systems, defined much of their governing philosophy, made rollout decisions and worked through the implementation and testing with AI coding tools.
One of the most important decisions was deliberately not deploying a capability that the system was technically capable of enabling.
The temptation
APEX had been running a quality-weighted retrieval mechanism in shadow mode.
The mechanism could observe what a future ranking algorithm would do without allowing those rankings to control production behaviour.
The obvious milestone was to turn it on.
The switch, rollback and testing existed. There had already been hundreds of evaluated briefs.
But the question was not:
“Can we enable it?”
The question was:
“Have we earned enough evidence to trust it?”
The gate
The go-live criteria required more than a functioning algorithm.
The system needed enough trusted signals and evidence that promoting apparently stronger signals actually correlated with better real-world outcomes.
At the 8 June 2026 decision point, the evaluation contained 282 briefs.
The ranking behaviour was stable.
But the trusted-signal count was still zero, and the system did not yet have the real performance evidence required to demonstrate that promoted signals actually produced better outcomes.
The reason was straightforward:
APEX had not yet closed the complete real-world publishing → performance → attribution → learning loop required to generate that evidence.
The decision
So I didn’t flip the switch.
The correct engineering outcome was:
Not yet.
That matters to me because AI systems create a very strong temptation to confuse capability with permission.
A model can produce an answer.
An agent can call a tool.
An automation can publish.
None of those statements establish that the system should be allowed to do so.
Purple Guard
That principle also shapes Purple Guard.
Guard started as an inference gateway and policy layer, but I have been pushing the design toward something more explicit:
Who is making this request?
Under what authority?
Which policy was evaluated?
Which model or provider was allowed?
Which action is being requested?
What evidence exists for the decision?
Can the operation be stopped?
Can it be rolled back?
Can we tell the difference between a control that is implemented, one operating in shadow mode and one that only exists on the roadmap?
That last distinction is particularly important.
Security documentation becomes dangerous when planned controls are described as if they already exist.
The system should tell the truth about its own posture.
The wider lesson
I originally thought model independence meant being able to change a model name.
It doesn’t.
That is portability.
Real independence means understanding the capability an agent requires, having alternatives capable of supplying it, proving those alternatives against evaluation criteria and designing graceful degradation when a dependency disappears.
The same applies at the provider layer.
Two model names routed through one upstream provider do not give meaningful resilience if one credential or provider outage can disable both.
Outcome
As of this September 2026 account, APEX and Guard are still being built.
That is part of the case rather than something I want to hide.
Some controls operate, some are being validated, and some autonomy remains deliberately gated.
The important outcome is an engineering philosophy that is becoming more concrete with every iteration:
Automation should earn authority through evidence, not receive authority because the technology is impressive.
For me, responsible AI is not about making an agent sound cautious.
It is about designing the system so that there are actions it genuinely cannot take until the required conditions are satisfied.
About this account
Based on my experience and dated project documentation. The private source material is not reproduced here. Results describe the period in the story; they are not a claim about today’s runtime state.