Tutto Applied AI
We build the systems, bridges, and infrastructure that let AI work inside your organisation - not just beside it.
How it works
The applied view
Most people have met AI as a chat window. You ask a question, you get an answer, you copy it somewhere useful. That is real, and it is the smallest thing this technology does.
The systems on this site differ in one specific way. The AI goes to your files, your database, your machine, and does the particular job your work is actually made of, on the first of every month, or every time a document lands, without being asked again.
Start here
A chat window answers you. A script does the work.
A script is nothing exotic. It is a written set of instructions your computer carries out on its own, in order, without you sitting there. Payroll is a script. So is the spreadsheet macro somebody in accounts wrote in 2014 that everyone is now afraid to touch. What has changed is not what a script is. What has changed is who can write one.
A worked example
The report nobody has time to run
Almost every organisation is sitting on a database: the system that records the orders, or the patients, or the cases, or the stock. Almost none of them can ask it a question. So somebody exports it to a spreadsheet once a month and rebuilds the same charts by hand, and the answer to anything urgent is: give me two days.
Point an assistant at that database and the two days become one afternoon, once. It reads the shape of the tables. You describe the report the way you would describe it to a new colleague. It writes the queries, runs them against the real data, checks the totals against a month whose answer you already know, and tells you where they disagree rather than papering over it. Then you tell it to do that on the first of every month, and it does.
Nothing uploaded
The database is read where it sits. No copy of it leaves the building.
Once, then monthly
The effort sits in the first afternoon, not in every repetition of it.
Every figure traceable
Each number traces back to the query that produced it, so it can be checked.
What is in this database? I have never seen the schema.
14 tables. Core: orders (2.1M rows), customers (84k), line_items (7.4M), returns (61k). Orders link to customers on customer_id; line_items to orders on order_id. Dates run Jan 2019 to Jul 2026.
Build the monthly margin report we do by hand: revenue, cost and margin by product category, last 24 months.
Query written and run against the live database. 24 months x 9 categories. Cross-checked June against your finance export: revenue matches to the penny, margin differs by 0.3%. Your export excludes freight. Flagging rather than reconciling silently.
Run it on the first of every month and put it in the shared folder.
Scheduled. Writes monthly-margin.xlsx to /Finance/Reports at 06:00 on the 1st. If a run fails it emails you rather than failing quietly.
Notice what did not happen. Nothing was uploaded. The queries ran against your database, where it already lives. The assistant wrote the instructions; your own machine did the work.
Why this matters
The awkward, specific jobs are the whole point
A general-purpose AI product is built for the average of everybody's work, which is another way of saying it is built for nobody's in particular. The jobs that actually eat your week are the ones no product was ever made for: the reconciliation only your firm does, the return in the exact layout your regulator insists on, the check that exists because of something that went wrong in 2019 and must never happen again.
None of those were ever worth building software for. The market for each one is a single company, sometimes a single department, occasionally a single person. That arithmetic is what has changed. Work that would once have justified a fortnight of a developer's time now justifies an afternoon of yours, which puts the long tail of small, specific, unglamorous work within reach for the first time.
One firm's format
Returns and submissions
The submission your regulator wants, in the layout it wants, assembled out of four systems that do not speak to one another. Nobody sells this, because you are the only possible buyer.
One team's judgement
Rules that live in someone's head
The reasons a claim gets flagged. The tells that make a supplier worth a second look. Written down once in plain language, then applied identically every time, including on the Friday afternoon when nobody is concentrating.
One person's week
The work between the systems
Reading the attachments, renaming the files, checking that two numbers agree, chasing the one that does not. Individually trivial. Collectively somebody's job.
In the field
The same three moves, in very different rooms
Every system we have built has the same shape. Point it at the real data. Describe the job in the language of the people who do it. Keep the work on hardware the client controls. What changes is the room.
Pythia
Litigation disclosure
150,000+ documents from a disclosure set, read on a machine standing in the room. Ask in plain language; every answer cites the document and page it came from, because an answer a lawyer cannot check is worse than no answer at all.
GTM
Business development
6,675 prospects profiled across nine countries. Open-weight models on the client's own hardware do the bulk of the reading and writing; a frontier model is called across a single auditable boundary, with identifying detail held back.
The SharePoint bridge
Microsoft 365
SharePoint records queried, created and corrected by asking, rather than by clicking through lists, and broken Power Automate flows diagnosed in conversation rather than by trawling run histories.
Each of these has a fuller account, with screenshots and example sessions, in the portfolio. Our work →
On your own machine
Local first, and not only for the reason you would guess
Privacy, obviously
Some material cannot travel
Privileged legal documents. Patient records. An acquisition nobody has announced. On-premise is not a setting somebody switches on in a preferences page; it is an architecture, and it is either true of your system or it is not.
It does not change under you
Stability
A cloud service is updated on somebody else's schedule, and a process that was defensible in March can quietly stop being so in June. A script on your own machine does the same thing next year that it does today, and changes when you change it.
The cost curve bends the other way
Economics
Cloud AI is priced per question, so the better it works for you the more of it you buy. Hardware you own is priced once. Open-weight models run on it at no charge per use, and a frontier model gets called only for the parts that genuinely warrant one.
Which AI
The model is a component, not the commitment
People ask which AI we use as though the answer settles everything. It settles less than you would think. We build with Claude most of the time, because it is currently the best at writing and repairing the code.
But what you are handed at the end is a folder: your instructions in plain language, the scripts that do the work, your data. Mistral will run it. So will an open-weight model on hardware in your own building, with nothing leaving the room. The choice is yours, and (this is the part that matters) it stays reversible.
On running a model locally
Running a model locally means downloading its weights (the file that is the model) and running it on hardware you own. No account, no charge per question, no network call. It is a genuine trade rather than a free lunch: open-weight models trail the frontier ones, and a machine able to run a large one is a real purchase. The useful pattern is usually both, with the local model doing the volume and a frontier model called deliberately for the few steps that need the extra capability, across a boundary you can audit. We will tell you which parts of your work fall on which side before you buy anything.
Where to start
Three ways in, depending on whether you would rather build it, have it built, or simply see one working first.
Build it yourself
Praxis: for one to four people, on your own use cases, from four private sessions to eight with your team. You leave with a working tool for your own work, not with notes about one. There are group evenings too, cheaper and more general, if you would rather look before you commit.
Have it built
A short diagnostic on your real workflows comes first, so that what gets built is the thing that was actually costing you, rather than the thing that was easiest to describe.
See a whole system
Pythia in full: a system that reads everything you hold and answers from it, on a machine you own. What it does, what it costs, and an open demonstration you can click through without speaking to anybody.
On the name
A pointer's entire job is to find the thing you are looking for and point straight at it.
That is step one, and it is step one of everything on this page. Out of all the material you are sitting on (the files, the database, fifteen years of email), the first useful thing anyone can do is find what matters and show you exactly where it is. Nothing else can start until that has happened.
Step two is how far you let it carry you. Some stop at the finding, which is already most of the value. Others let the scripts run the rest of the way: the report assembled, the rule applied, the work done before anybody thinks to ask for it. Where you draw that line is yours to decide.
What is the job that eats your week?
Bring us the specific one, not the impressive one. Thirty minutes is usually enough to tell you honestly whether this is worth your time.
Learn to do it right, the first time.
Praxis: training on your own documents and process. The rules, a scorecard for each job, what to hand over, then the build.