The Real AI Agent Is Software

I thought that, since it was a Tuesday afternoon and I had nothing better to do, I would look at writing an article about my thoughts on the Australian Government.

No, not about whether I like the government or not. I wanted to look at the document they are using as their standard for building with AI.

Released in June, the policy update comes with the exciting and engaging title Agentic AI addendum to the AI technical standard for Australian Government. From now on, we can just call it "the addendum".

The first thing to consider when thinking about AI is how quickly the industry has changed.

In 2026 alone, there have been three major switch-ups: the emergence of agent harnesses and frameworks such as OpenClaw and its more attractive cousin, Hermes; the release of Fable 5, and its restricted twin Mythos 5 — the same model with the cyber safeguards taken off, handed only to the people the vendor decided had a good enough reason; and the emergence of cheaper and smarter Chinese models such as Kimi K3.

Among all of these changes, the government has decided to create a framework for how these systems should be built.

Why now?

The adoption of AI systems, especially generative AI, has accelerated at an unprecedented pace.

Stanford's 2025 AI Index reports that organisational AI use rose from 55 per cent to 78 per cent in just one year. Eurostat has EU businesses with ten or more staff going from 13.5 per cent to 20.0 per cent between 2024 and 2025. Six and a half points in a year.

There had to be some kind of technical standard in place. I am not arguing with the premise of the standard. I will, however, argue with the way parts of it have been written.

The bad: the definition of an AI agent

The technical standard spends a lot of time explaining what an AI agent is. The problem is that the definition it gives could easily apply to many software systems that are not agents.

The addendum defines an AI agent as:

A software-based system that perceives inputs from its environment, maintains or updates an internal state, and selects and executes actions using APIs or other tools to achieve defined goals within assigned permissions and constraints. It may plan, learn from feedback when permitted, and self-monitor its behaviour to improve performance over time, while operating within defined governance, oversight, and control mechanisms.

Let's break down that first sentence.

Now, the second sentence is where the interesting words live. Plan. Learn from feedback. Self-monitor.

Except every one of them is sitting behind the word may.

Optional. So the part of the definition that separates an agent from a thermostat is the part you are allowed to skip.

So, without sitting in the cheap seats just heckling — the addendum does say the thing I want. It says it about four hundred words later, in the background section, in a list of common methods and technologies.

Put it in the definition. The definition is the line people will paste into a procurement document.

The "Control Tower"

Now that we have got that out of the way, there is another term in the addendum that even someone like me, who has been building these systems since ChatGPT was released, had not heard before.

They call it a "Control Tower".

The addendum defines it as:

A centralised architectural governance layer that monitors, manages, and ensures secure agentic AI operations. A control tower can be used by business, system owners, and governance teams to monitor what agents are running, risks, security, costs, and compliance with regulations.

The idea itself is sensible.

In software engineering, we already have something similar. It is usually called observability. Production software needs monitoring because, when something goes wrong, you need to know what happened and who or what was responsible.

A Control Tower is broader than that. It is not just about whether the system is working. It also covers risk, security, cost and compliance.

For an AI system, that means capturing every step of a run. That happens to be the same list you need for an audit trail, so rather than write it out twice, it is further down.

So, while I think "Control Tower" is a slightly silly name, the idea behind it makes sense.

Graceful recovery needs more detail

There is also a lot of discussion about graceful recovery in the addendum.

That is all well and good, but there does not seem to be much practical guidance around what graceful recovery should actually look like.

If a system fails, it has about five options. The addendum does not tell you how to choose between them.

Pick one before you go live. The default is worse than all five: the agent fails quietly, and your team finds out from the client.

Maybe I am nitpicking, but parts of the recovery guidance land at roughly the altitude of make sure the system does not fail.

That is a reasonable goal. It does not explain what an organisation should actually do when the system does fail.

The good: use agents where they make sense

The addendum talks about narrowing the scope of where AI is allowed to make decisions. I think this is a good practice.

Why use an agent where it will "probably work" when you can use programming to create rules so it will "definitely work"?

Ultimately, an LLM is still a probability engine. It predicts the most likely response based on the information it has been given. That means its output can vary, and that variation creates risk in a business environment.

Ninety-seven per cent accurate is a great demo and a terrible referral process. The three per cent is a patient record with someone else's name on it, and you will not hear about it from the agent.

Traditional software can still have bugs, of course, but it is generally more predictable. If the same rules and inputs are used, you normally expect the same result.

Here is the neat part, though: you can use AI to build these traditional systems anyway. Most of what we ship is exactly that. An agent did the building, and what runs in production is boring, deterministic code that does the same thing every Tuesday.

So, hot tip: do not pick an agent when a programmed system can do the job, particularly if consistency is important.

There are also situations where a little randomness is not a major problem. Content generation is a good example. You are often tweaking the system anyway, and if it gets something wrong a small percentage of the time, you can review the result and ask it to try again.

That approach would not be suitable for every task. You probably do not want an AI agent randomly deciding how much money to pay an employee or whether a customer should receive access to an important system.

Audit trails are essential

Under the silly name, the addendum also mentions that audit trails are essential.

I agree with that.

After ten years of building production software, I have found that it is rarely the obvious bugs that cause the biggest problems. It is usually the subtle ones.

Imagine that you are building a lead-finding agent. The agent finds a genuine sales lead but gets the company name wrong. That mistake may be difficult to notice among the hundreds of messages and records the system has created.

Swap the industry and the shape is identical. An intake agent that summarises a referral perfectly and files it against the wrong patient looks like a success in the log and a problem in the audit.

So this is what you want captured for every single run:

In other words, it shows you the crime scene in detail.

That may sound dramatic, but when something goes wrong in a large system, you need evidence. Without an audit trail, you are left trying to work out what happened from the end result.

Verification loops

The addendum also talks about feedback and verification loops that allow systems to improve over time.

This is becoming a necessity rather than a nice-to-have for agentic systems.

A verification loop can be as simple as telling the system:

Make sure you verify "X" by doing "Y".

For example, an agent could be told to confirm a company name against a trusted database before sending a message.

However, checking a result and improving a system are not exactly the same thing. A verification loop checks whether the current result is correct. A feedback loop records what happened and uses that information to improve the system later.

That improvement might involve changing the prompt, adding a new rule, updating a tool or replacing the model.

None of it is exotic. It is refusing to let a machine act on something it has not checked.

Final thoughts

It is probably a little early for the government to create a complete standard for building AI systems. Many people are still figuring out what building with AI looks like and what capabilities these systems can provide.

However, the addendum does include some sensible software practices that businesses should start using now:

• Keep AI decisions within a narrow scope.
• Use programmed rules where consistency matters.
• Monitor performance, cost and risk.
• Keep detailed audit trails.
• Verify important information before taking action.
• Decide in advance what a failure should do — retry, fall back, hand it to a human, or stop and say so.

So, while I think the addendum's definition of an AI agent is too broad and its advice on graceful recovery needs more detail, there are some useful ideas in it.

I will be using the name "Control Tower" in place of observability from now on.

Sorry, government. That one is sticking.

We design and build agentic systems for Western Australian businesses, and everything in that trace diagram is captured in ours. Not because a standard told us to, but because the alternative is guessing.

If you cannot answer which model did this, what it was given, and who signed off for a run that went wrong last Tuesday, you do not have a Control Tower. You have a hope.

Book a 15-minute call and I will tell you which of the six you are missing, even if you never work with us.

Sources cited: Digital Transformation Agency, Agentic AI addendum to the AI technical standard — digital.gov.au/policy/ai/agentic-ai-addendum. The AI agent definition and the passage on language models are quoted from its Background page; the Control Tower definition is Criterion AGT.8.2 in its Monitor lifecycle statements. Stanford HAI, AI Index Report 2025 (organisational AI use, 55 to 78 per cent). Eurostat, Use of artificial intelligence in enterprises, released 11 December 2025 (EU enterprises with 10 or more employees: 13.5 per cent in 2024 to 20.0 per cent in 2025). Anthropic, Claude Fable 5 and Claude Mythos 5.