FACTORY OPERATIONS · SEPTEMBER 2026 · 8 MIN
The most expensive GPU in your estate is a busy one
A cluster at eighty-five per cent utilisation serving a drifted agent has zero effective utilisation. The spend is entirely real. The outputs are wrong. Nothing alerted.
The utilisation conversation is the one everybody is having, and it is worth having. A hundred-thousand-GPU cluster represents several billion dollars of investment. At the utilisation figures that keep appearing in operator data, the large majority of it is idle at any given moment. That is a working capital problem wearing a technology costume, and the arithmetic is not in dispute.
But utilisation is a dangerous metric to optimise alone, because it is trivially gameable and because the worst state in an AI factory scores well on it.
The state nobody measures
Take a cluster running at eighty-five per cent. Any operator would be pleased with that number. Now suppose the agent it is serving has drifted — output quality down from the low nineties to the high sixties over a few hours, because a connector changed or an instruction was edited outside change control.
The effective utilisation of that cluster is zero. Everything it produces has to be redone, reviewed or discarded. You are paying full price for the compute and then paying again downstream to correct what it produced.
And nothing fired, because nothing crashed. No threshold was breached. The GPU metrics were perfect throughout — which is precisely the point. Infrastructure telemetry cannot see output quality, because output quality is not an infrastructure property.
Why the two numbers have to be multiplied
This is the argument for treating estate efficiency as utilisation multiplied by quality rather than utilisation alone.
The multiplication has a useful property: it cannot be gamed by running junk work to lift a chart. Fill idle capacity with low-quality output and the composite does not improve. It is also the number a board can be given without a page of caveats, because it collapses the two things that actually determine whether the asset is productive.
- High utilisation, high quality. The asset is working. Scale it.
- Low utilisation, high quality. Idle capital. Recoverable, and the cheapest capacity you will ever acquire.
- High utilisation, low quality. The expensive state. Paying twice and generating downstream cleanup.
- Low utilisation, low quality. Rare, and usually means nobody owns it any more.
The detection problem underneath
None of this works without being able to measure output quality continuously, which is harder than measuring utilisation and is the reason most estates do not do it.
It requires scoring behaviour across several dimensions against the baseline the agent shipped with — semantic coherence, factual grounding, instruction adherence, tool call accuracy and so on — continuously rather than by sampling. And it requires causal attribution, because an anomaly flag with no cause attached generates a meeting rather than a fix.
Detecting drift in minutes instead of hours is worth more than the next ten points of utilisation, and costs a great deal less.
The capital argument
Finish on the comparison that matters, because it is the one that gets budget.
Ten points of utilisation on a hundred-thousand-GPU cluster is ten thousand GPUs. Buying that capacity costs in the region of three hundred million dollars and takes most of a year to land. Recovering the same capacity from hardware you already own is an operational exercise measured in weeks.
The gap between those two options is the entire business case, and it exists before you count the compute currently being spent on producing answers that are wrong.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
SECURITY · SEPTEMBER 2026 · 7 MIN
Prompt injection is a behavioural signature, not a string
An agent whose objective has been corrupted mid-session passes every individual inspection. The attack is not in any single message — it is in the shape of the session.
Most prompt injection defences are content filters wearing a new name. A library of known malicious phrasings, some regular expressions, maybe a classifier trained on the phrasings that have been published so far.
That approach has a structural ceiling, and everyone building it knows what it is: it catches what it has seen. Rephrase the instruction, encode it, split it across turns, or embed it in a document the agent retrieves, and the filter has nothing to match on.
The attacks that actually matter in a fleet
The categories that concern me in a production agent estate are not the ones that arrive in the first user message. They are the ones that develop mid-session.
- Goal hijacking. An agent's objective is corrupted through an adversarial tool response. It continues operating, competently, toward a different aim than the one it was given.
- Session memory corruption. Context poisoned gradually across turns. Each turn is clean in isolation. The corruption exists only in the accumulation.
- Indirect injection. The payload arrives in retrieved content the agent was authorised to read, from a source that was legitimate when it was approved.
What these share is that no single observation is anomalous. Inspect any individual turn and it passes. The attack is a property of the sequence, which is why perimeter tooling — which sees instructions arrive and results leave — is structurally unable to detect it. Not badly implemented. Standing in the wrong place.
The behavioural alternative
If the attack manifests as a change in how an agent behaves, then measure how the agent behaves and watch for the change. That sounds obvious and it is, but it requires two things most monitoring does not have.
First, a baseline. Not a policy describing what the agent should do, but a statistical picture of what it actually does when operating normally — across coherence, grounding, instruction adherence, tool call patterns and completion shape.
Second, drift detection against that baseline rather than against a fixed threshold. The signature of a corrupted objective is a sustained departure from the agent's own normal behaviour, which is exactly the shape statistical process control was built to find.
Why this generalises
The property that makes the behavioural approach worth the additional complexity is that it does not depend on having seen the attack before.
A novel phrasing still has to produce a behavioural change to accomplish anything. If it does not change behaviour, it did not work.
That is the whole argument. Content scanning generalises poorly because language is infinitely variable. Behavioural detection generalises well because the attacker's objective is constrained: to achieve anything at all, they have to make the agent do something it would not otherwise do.
The practical caveat
Behavioural detection has its own failure mode, and it is worth naming. Legitimate change also looks like drift. A new tool version, an updated system instruction, a shifted traffic mix will all move the baseline.
Which is why detection is only half of it. Without causal attribution — the ability to say this drift began when this specific thing changed — you generate a stream of alerts that operations learns to ignore inside a month. Attribution is what makes the signal actionable, and it is also what tells you, quickly, that the cause was an ordinary deployment rather than an adversary.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.
COMPLIANCE · AUGUST 2026 · 6 MIN
Article 12 is a date, not an ambition
Evidence assembled before an audit is a documentation project. Evidence produced by the system running is a by-product. Only one of those survives contact with a date.
There is a familiar pattern in how large organisations handle a regulatory deadline. The obligation is identified, a programme is stood up, artefacts are assembled, and a binder is produced shortly before the date. It works, more or less, for obligations that are about documenting a stable system.
It does not work for obligations about what a system did, because you cannot assemble a record of events that were never recorded.
Three obligations, one property
The EU AI Act provisions that matter most for a production agent estate share a characteristic worth noticing.
- Article 12 — record keeping. Automatic logging of events over the system's lifetime, with traceability appropriate to the intended purpose.
- Article 14 — human oversight. Evidence that a natural person could and did oversee operation, including the ability to intervene.
- Article 11 — technical documentation. Documentation kept current, not produced once at conformity assessment.
Every one of them is about the operating period rather than the system's design. That means the compliance question is not whether you can produce a document by the date. It is whether the events of the preceding period were recorded as they happened.
If they were not, no programme can retrofit them. That is the whole difficulty, and it is the part that tends to be understood late.
What a human oversight record actually needs
Article 14 is the one most often misread as a policy requirement. Institutions write a procedure describing how humans oversee the system and consider the obligation addressed.
A procedure is not evidence of oversight. An evidentiary record needs the decision that was presented, the person who reviewed it, what they decided, the rationale, the timestamp, and what happened next. Produced at the moment of oversight, not reconstructed from memory and a calendar invite.
Which has a design consequence people do not always like: if your remediation is fully autonomous for everything, you have no human oversight records to produce. Tiering matters — autonomous where the consequence is low, a named human where it is not — and the human tier is where the Article 14 evidence comes from.
The by-product principle
The only approach I have seen survive is to stop treating evidence as an output of a compliance process and start treating it as an output of the system operating.
If producing the evidence requires a project, you will be producing it late, incompletely, and for the last period rather than the current one.
When the audit log is hash-chained at write time, when every oversight decision is captured at the point of decision, and when the technical documentation is generated from live configuration rather than maintained by hand, the compliance position is a query rather than a programme.
The commercial reading
The penalties get quoted most often, and they are substantial. But for operators I have spoken with, the sharper exposure is different: an inability to demonstrate compliance stalls deployment.
The programme does not get fined. It gets paused, while governance catches up — and the business case for the whole estate pauses with it. That is the outcome worth spending money to avoid, and it is considerably more expensive than the instrumentation that prevents it.
Vyasa Murthy is the founder of Venture Vertex LLC.
Write to vyasa.murthy@venture-vertex.com — the most useful replies start with why this will not work in your environment.