The limiting factor on most AI work today is infrastructure, not model capability. If you have been treating AI as a smart contractor you bring in for a task, this is the alternative, and what I mean by “AI-native”.
The contractor pattern: bring AI in, paste in some context, get an answer, dismiss it. If the answer is good, great. If wrong, try a better prompt. If it forgets something, that is your fault for not pasting enough. If it does something dangerous, tighten the instructions and hope. It can be useful, but it stays shallow.
An AI-native operating environment starts somewhere different: the limiting factor is usually not model capability, it is infrastructure. The hard problem is not getting the model to generate text or code; it is creating the conditions under which an agent can operate autonomously, repeatedly, safely, and with enough context to be useful without being micromanaged.
That changes the human role. You stop building things yourself and become an architect of the infrastructure that lets AI do most of the building. The job is to make sure the AI system has the right context and structure, working with it continuously so its memory keeps up with what we have built and its controls keep up with the trust we are placing in it.
Being AI-native is not about using Claude, Gemini or ChatGPT a lot, but about building an operating environment around them: memory systems, retrieval pipelines, control hooks, daemons, workflow skills, review mechanisms, and safety layers that let the tools function less like a chat interface and more like an operator.
At first things are closely monitored, but the important move is that every detected problem gets a thorough root cause analysis and infrastructure controls that prevent recurrence. Over time this compounds, from a system that gives useful answers but cannot be left alone, to one trusted as much as a human.
| Not AI-native | AI-native |
|---|---|
| You ask the model to do tasks | You maintain the memory, controls, and permissions that let the model operate |
| Context is assembled ad hoc in prompts | Context is continuously accumulated, normalised, indexed, and retrieved |
| Safety is “be careful” in instructions | Safety is enforced structurally with hooks, state checks, gates, and audit trails |
| Failures are corrected socially | Failures are systematically analysed and controls are introduced which make the failure mechanically difficult to repeat |
| Trust is binary: on or off | Trust expands in concentric rings as controls mature |
Principles
A few principles for operating in this style:
- Make AI act as the process spine. If multiple steps or systems are involved, never copy-paste or manually coordinate across tools. The AI should do that, ideally using APIs or plug-ins.
- Prioritise controls strongly. When something is not working, do not just fix it; understand how it happened, what controls failed, and how to restructure things so it physically cannot happen again.
- Rebuild periodically. Things will (and should) evolve organically, and like any system, AI builds up tech debt. Because it evolves faster than human-built systems, the debt builds up faster too. The good news is that rebuilds can be done quickly. Spot when they are needed and do not put them off.
Four opportunities for mature organisations
-
Tool access. Many organisations’ information-security postures block a lot of AI tools. It is a tricky balance: we need to be safe, but AI value increasingly gets unlocked through agentic workflows that stitch multiple systems together. Which tools are right for each task evolves, so tool access needs to keep up.
-
Data layer. For many firms, data is stored in multiple places. Using it effectively requires clean, well-documented data and Model Context Protocols (MCPs) in place. Without these, only a narrow group can use the data.
-
Systems are as important as tools. Much of what organisations focus on is people confidently using AI tools, which matters. But AI use is too often discussed in tool-level isolation (eg more people logging into Gemini). For broad-scale adoption to be safe, infrastructure (hooks, daemons, MCPs, memory and instruction systems) needs to be dealt with on a par with tool use.
-
Subject matter expertise should be used directly. The old process of (1) “subject matter expert designs”, (2) “they write specs or user stories”, (3) “Tech builds” is not optimal in the world of AI. There is an unnecessarily large separation between the end user / subject matter expert (SME) and the AI system. The AI is capable of understanding the SME, and with the right control infrastructure it can build what the SME needs directly. The most effective way to become AI-native is to empower SMEs to build AI systems directly, by partnering with them on the systems and controls that make it safe.
Practical next steps
A few options for how some of this could be approached:
-
Get people using AI enthusiastically. Hackathons and similar to get everyone using AI tools. Encourage system builds, not just tool usage. Give people development time and budgets, including for personal tinkering and “vibe coding”.
-
Unblock tool access. Two streams:
- Get a far wider number of AI tools into people’s hands, with a process for rapid approval of new tools. Hard, but given the pace of market change, ideally days not weeks.
- The above will not be perfect; consider sandboxed environments and personal training budgets where people can use AI more in their personal lives.
-
Data access. All data layers with MCPs in place and working.
-
Continue iterating where there is business value. Identify two to five key improvements, align resources behind them (personal AI budgets are a good way to flush out people with interest), and give those teams strong exec support.
If you are working through this in a real organisation and want to compare notes, contact details are on the about page.