APPROACH
Most AI initiatives begin with a tool and go looking for a problem. Mine begin with the problem — a decision that is too slow, a process that only works when one person is in the room, data that exists but never arrives where it is needed — and only then ask where AI, automation or existing software belongs. The result is not AI on top. It is a company that works differently, with AI built into the way work gets done.
01 BUSINESS PROBLEM
Start with the friction, decision or bottleneck that actually matters.
02 SOURCE OF TRUTH
Ground the system in the data, documents and signals the business trusts.
03 PROCESS
Map how work actually moves from input to decision to action.
04 RULES
Encode the constraints, standards, approvals and exceptions that govern the work.
05 CONTEXT
Give the system the business knowledge it needs to act intelligently.
06 MODEL / AGENT
Apply intelligence inside a defined operating system — not in isolation.
07 VALIDATION
Check quality, completeness and compliance before anything moves forward.
08 HUMAN GATE
Keep judgement and authorisation where human control actually matters.
09 OPERATIONAL OUTPUT
Turn the result into something the business can use, trigger or act on.
The model is one layer. The layers around it make it reliable.
The first conversation is about what should become better: a decision, a handover, a report nobody trusts, a production step that cannot be repeated. Where is time, quality or information lost today, what would good look like, and who owns it? If there is no measurable problem, no data access and no owner, AI is not the answer yet — and I say so.
Before anything is designed I take the current state in read-only mode: processes as they are actually run, the systems involved, the data they hold, who owns each step, and the exceptions that live only in someone's head. Interviews, a live look at the systems, a data or repository audit — whatever the situation needs. Live systems are not touched in this phase.
Almost every fragmented process has the same root: the same information lives in several places and nobody has decided which one is right. So for each kind of information — ERP, shop, ledger, repository, decision log — the architecture starts with one question: which system is authoritative, who may write to it, and how does everything else read from it? AI on top of an undecided truth simply produces confident answers faster.
I break work down into triggers, steps, decisions, handovers, approvals, exceptions and outputs, then ask which steps are deterministic and which genuinely need interpretation. Steps are removed, simplified, merged, automated conventionally, or redesigned with AI. Conventional automation wins where rules are fixed and writes are critical. AI earns its place where research, classification, synthesis, anomaly explanation or unstructured input create value. Most good solutions are hybrid; the worst mistake is building AI where a deterministic integration would have been better.
A working AI system is defined by more than its model: system limits, data sources, APIs and connectors, model and provider routing, agent roles, permissions, read/write boundaries, protected actions with human gates, context and memory, evidence, versioning, rollback, monitoring — and who owns all of it after handover. Governance is designed in from the first sketch, not audited in at the end.
Implementation happens in the smallest unit that is complete and verifiable: one bounded change with a clear current state, a defined scope, concrete tests and reviewable evidence. Work units keep speed and control in the same hands, and they let internal teams, external developers or agencies contribute without losing the architecture.
Nothing is done because an agent says so. Systems are validated against real commands, tests, builds, browser and device checks, screenshots and diffs — evidence a reviewer can look at. The same standard applies to business results: a pilot that works is not a production process until someone owns it and its failure modes are visible.
THE HUMAN + AI OPERATING MODEL
I run a system in which different capabilities have different jobs, and human judgement stays where it matters.
| Role | Responsibility |
|---|---|
| André | Business judgement, architecture, priorities, commercial context, decisions and approvals. |
| Orchestrator AI | Context synthesis, research, work-unit planning, review and handover. |
| Specialist agents | Coding, analysis, creative production and QA support — each routed to the task it is reliable at. |
| Runtime and enterprise systems | Source of truth and actual state: ERP, commerce, finance, repositories — where execution happens. |
| Human gates | Protected actions, final business decisions, deployment and publication, subjective brand and creative choices. |
The point is not many AI agents. It is controlled specialisation: the right capability for the exact task, routed by reliability and evidence, with explicit boundaries around what may be read, written and released.
Controlled specialisation — not lots of AI agents.
A system only I can run is not finished. Handover includes the documented architecture, code, runbooks, process definition, decision log and do-not-regress rules, tests and evidence, deployment and rollback procedures — and a named business owner and technical owner. "The AI" is never the owner. After go-live, performance data, exceptions and the questions people actually ask feed back into rules, context and process. That is what turns a working pilot into a capability the company keeps improving without me.
Typically with a focused review — of AI opportunities and architecture, of a process and its operating model, of enterprise-system integration, or of a commercial decision — or with a scoped build or pilot. The first conversation has no package attached: it starts with the problem, the systems involved and what better would mean for you. From there we define the smallest first scope worth doing.
WHERE THIS LEADS