Riccardo Tagliavia Applied AI Architect
It's finding the one place in a business where AI actually moves money — and building the systems that keep what your team learns from leaving with the people who learned it.
What I do
Both come down to the same decision: what should a system know, and when. Get that right and which model you use becomes almost an implementation detail.
Leverage
I start with how the business actually makes money — not with a list of AI capabilities. Once the constraint is clear, I aim retrieval, automation and guardrails at that one point instead of spreading them across a roadmap.
How that worksMemory
AI-assisted teams ship faster than they can document. The code lands, the reasoning behind it doesn't, and it leaves when people do. That's a slow loss of the asset you're actually paying for.
How that works02 / Leverage
Most AI programmes start with the technology and then go looking for a use case. That's usually why they stall after the pilot. I run it the other way round — four steps, in this order, because each one narrows the next.
01
Where revenue comes in, where cost goes out, and which handoffs make work sit and wait. This is a map of the money, not an audit of your tooling.
02
The step where delays, errors or forgotten context quietly add up to real money. If it can't be stated in a sentence with a number in it, it isn't the right one yet.
03
Answers grounded in your own data rather than a general-purpose model's guesswork, connected to the tools that do the work, with clear limits on what runs unsupervised. The system is the product; the model is swappable.
04
Track what worked and feed it back, so the system gets measurably better at the one thing that pays. Skip this and you have a demo that ages badly.
03 / Memory
AI made writing code fast and made understanding it optional. The change ships, the reasoning behind it never gets written down, and six months later nobody can say why a critical piece works the way it does. Every one of those gaps is knowledge your company paid for and no longer owns.
What else breaks if this changes, recorded next to the change itself — not in a wiki nobody opens.
What happens when it runs twice, or half-succeeds, written down where the next person will actually look.
The reasoning behind the non-obvious call, so nobody spends a week rediscovering it the hard way.
Documentation as a good intention doesn't survive a deadline. These are checks built into how work already flows, sized so they cost almost nothing on routine changes and bite only where the risk is real.
01
Map what's fragile, under-owned or far-reaching while the code is still unfamiliar. Done once, it saves everyone after you from finding out by breaking something.
02
Guardrails scaled to how risky the change actually is. A typo fix shouldn't carry the same ceremony as a change to how payments settle.
03
A short check of the finished change against what was actually understood, with a verdict that can't be waved through when the change touched something critical.
04 / Case study
I wanted to know whether the memory problem above could actually be solved, so I built the thing that would prove it. Engram gives AI coding assistants a memory of the project they're working on — the decisions, the lessons, the reasoning — and hands back only what the current task needs. It started as a study. It's becoming a product.
Case study · SaaS in preparation
05 / Writing
Longer arguments about where AI actually helps, and where it quietly costs you — written up as I work through them.
06 / Contact
Whether you're working out where AI belongs in your operation, or shipping fast and losing the reasoning behind it — send me the shape of the problem and I'll tell you honestly whether I'm the right person for it.