Leverage
Turning an operational pain into a revenue flow
I start with how the business actually makes money — not with a list of AI capabilities.
How that worksRiccardo Tagliavia Applied AI Architect
The hard part was
never the model.
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
Two problems, one discipline.
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.
Memory
Keeping what your team learns inside the company
AI-assisted teams ship faster than they can document.
How that worksI work with operators who already have a business, not a slide deck. Advisory and build. Panama City, remote-first.
02 / Leverage
Where AI actually moves money.
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
Map how the business earns
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
Find the one point worth attacking
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
Build the system around it
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
Make it improve on its own evidence
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
Your team is shipping code nobody fully understands.
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.
Name what it depends on
What else breaks if this changes, recorded next to the change itself — not in a wiki nobody opens.
Spell out how it fails
What happens when it runs twice, or half-succeeds, written down where the next person will actually look.
Record why, not just what
The reasoning behind the non-obvious call, so nobody spends a week rediscovering it the hard way.
Three moments where understanding gets checked
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
Before anyone touches it
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
While the work happens
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
Before it ships
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 / Proof of concept
Engram
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. A study. Working prototype, measured on my own repos.
Proof of concept · Working prototype
The memory layer your codebase never had
- Assistants pick up where the last session left off, instead of starting cold
- The reasoning behind past decisions stays findable, by people and by machines
- What proves useful surfaces more often; what doesn't quietly sinks
05 / Writing
Notes from the build.
Longer arguments about where AI actually helps, and where it quietly costs you — written up as I work through them.
06 / Contact
Tell me where it hurts.
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.