Practical writing on getting AI into production: framing, ontology, data, agents, deployment and what happens after go-live.
A model version is deprecated with a few months' notice. Nothing is broken yet, but your prompts and thresholds were tuned to it. How a managed service plans for the swap.
An ERP database knows what is true now. Agents, models and audits need to know how it got there. Why an AI-native system needs a lakehouse beside SQL.
Year one ships pilots and energy. Year two is when sponsors move, models change, the partner is still on site and the cost has no owner. What to set up before it starts.
How Apache Paimon keeps a continuously updated table readable: primary-key tables on an LSM tree, merge engines, changelog producers, tags, compaction cost.
XTable and Delta UniForm let one set of Parquet files be read as Delta, Iceberg and Hudi. That removes a copy and adds tests your AI SDLC has to own.
An on-device agent on Android XR spans the glasses, a host phone, the cloud and your own systems. Permissions, observability and upkeep have to cover all four.
Glasses with an AI agent demo beautifully. A pilot worth funding names one task, the data it will touch, how it is measured, what it costs and what stops it.
Apache Hudi updates single records in a lakehouse as fast as the ERP changes them: timeline, record index, Copy-on-Write, Merge-on-Read, CDC, deletion by key.
An operational agent needs current orders, stock and limits without polling the production database. How CDC, Flink and a Paimon table give it that state.
Field AI business cases count the model and the software and forget the devices. Who enrols, updates and replaces them decides the real cost of owning the system.
Knowledge drifts to the supplier and the support contract grows. For an AI system the opposite works better: a handover schedule and a declining support tier.
Iceberg keeps a table as an immutable metadata tree with one pointer in a catalogue. That is why rivals read it, and why the catalogue is the real lock-in.
Lights-out proposals tend to lead with machines and models. The ones worth trusting lead with exceptions, read-only access and what should stay staffed.
Delta Lake is the format under Microsoft Fabric and Databricks. The platform runs the log; retention, deletions, feature upgrades and service jobs stay yours.
The workshop shows people what is possible. The weeks after show them what is in the way, and that is where training is won or lost.
The three table formats promise the same things. What separates them is who holds the catalogue, which engines must write, and how often the rows change.
Per-project approval gates slow delivery and still miss the real risks. Governance that keeps pace uses proportionate lanes and evidence teams already produce.
Ownership of an AI application is decided in the first week, not at handover. What to agree before the work starts, and the questions that reveal a hidden dependency.
Row groups, statistics, page index, Bloom filters and codecs decide how many bytes an engine reads. What an agent tunes in Parquet and what an engineer decides.
An ontology project is easy to sign off as a careful diagram. What should remain for the model to outlive a quarter, and how to spot it in the proposal.
Straight-through processing is the headline number of every automation programme and the easiest one to flatter. Four definitions decide whether it means anything.
A spec-driven pilot without a stopping rule never fails, it just gets extended. Agree what evidence means widen and what means stop before the first spec is written.
If a transformation partner is as involved in month nine as in month two, something has gone wrong. How to write the decline into the contract, and check it.
Avro carries an event between systems without losing a field. Parquet lets a report read two columns of forty. Enterprise data needs both, each for its job.
When an agent does something nobody intended, the first hour depends on decisions made months earlier: its identity, its logs and who can switch it off.
Spec-driven delivery works in the pilot. Rolled out to twenty teams, gates get bypassed, reviews thin out and the dashboards stay green. How to keep it honest.
Long use-case lists feel like progress and function as a way of avoiding a decision. What replaces them is shorter, harder to write and actually gets built.
How Avro carries an event between an ERP, a warehouse and an AI system intact: the schema, the registry, the compatibility rules, and who approves a change.
Design proposals for AI products usually look like any other. A few details show whether the author has ever designed for a system that is sometimes wrong.
Every transformation plan has a technology budget and an adoption paragraph. That imbalance predicts the outcome more reliably than anything about the technology.
AI data work often stalls on business decisions rather than on technology. Which decisions those are, how much time they take, and what happens when nobody makes them.
A demonstration shows an agent on its best day. The questions that separate a production supplier from a demo supplier are about bad days, logs and limits.
Most attempts to make agents safe happen in the prompt. Almost all of the real safety comes from the tool layer, which is an engineering decision.
AI business cases fail less often because the number is wrong than because nobody can see what the number rests on. Write the assumptions down first.
The metric that decides whether an AI feature saves anybody time is not accuracy. It is how long it takes a person to confirm or correct what it produced.
Software teams consult the people who know the work. AI product teams need them inside, with time set aside, because the product is measured against their judgement.
Field pilots are often run to prove that a system works. The useful ones are run to find out how it fails, and they need a different crew, scope and exit criteria.
Pipelines that mix models with ordinary systems retry constantly. Unless every step that changes state is idempotent and recorded, a retry becomes a duplicate.
Without a way to score changes, an AI codebase gets slower every month. Teams feel it around month three and usually blame the wrong thing.
A conventional SLA measures uptime, and an AI system rarely goes down. What belongs in a contract for running one, and which promises should worry you.
Once an agent writes and runs code, typed tools no longer bound it; the environment does. Isolating the process is the easy half. The rest is what can leave.
In many plants the judgement that keeps production running sits with a few experienced people. Capturing it pays off whether or not the lights ever go out.
Executives rarely need to use AI tools better. They need to judge proposals, costs and risks well enough to decide, and that calls for a different half-day.
When search returns something technically related and practically wrong, the usual response is to tune the retriever. The usual cause is elsewhere.
In an AI system, behaviour changes when the prompt, the model version or the retrieval index changes. Release and rollback have to treat them as one versioned unit.
Freshness is the quietest failure in an AI system. Nothing errors, nothing alerts, and the answers are perfectly consistent with a version of reality that has moved on.
A live AI feature with unmeasured quality becomes a liability the day its model is retired or its bill grows. What taking it over involves, and what to expect from it.
Most AI policies are written to satisfy a risk register and are ignored within a month. The version that works is shorter, more permissive and considerably more useful.
Interviews, modelling and implementation can be bought. Deciding which definition of customer each system means cannot, and that is the real cost of the project.
The budget case for agent-written code is often a headcount case. What actually changes is where engineering time goes, and which skills become scarce.
An AI system changes the work around it: who checks, who takes the exceptions, who decides. If nobody redesigns that, the old process carries on beside it.
Conventional monitoring watches for things that stop. The failure mode that matters here produces no error, no alert and perfectly formatted answers that are quietly worse.
Model choice, retrieval depth and extra checks each buy quality with money and seconds. Left to engineering, those trades still get made, just never on purpose.
In an automated process the exception path decides the result: what reaches a person, who that is when nobody is on shift, and how the decision gets back in.
Field systems are rejected for reasons that never appear in a requirements document, and every one of them is visible within two hours of standing where the work happens.
An in-house design team knows your users and product. What it usually lacks is a language for software that is sometimes wrong, and that is quicker to add than to hire.
A ready-made connector brings code that runs with your credentials and tool descriptions your model reads as instructions. It deserves dependency discipline.
Proposals for AI data work look alike until the first month. The questions that tell you, before signing, whether a provider builds trust in your data or a platform.
Generation got ten times faster and review did not. Teams that measure only the first half accumulate under-reviewed code, and the debt arrives all at once.
Pull requests, velocity and lines of code all rise when agents write the code. None of them says whether delivery improved. A few measures still do.
Agent proposals tend to promise a share of work done without people. The number that decides the investment is the full cost of a finished task, people included.
Strategy proposals look alike on paper. A handful of questions about pricing, interviews and what the provider sells next separate the useful ones.
Unattended production is rarely blocked by robotics. It is blocked by the judgement three experienced people carry, which exists nowhere a system can read.
Field AI projects fail on connectivity, gloves and devices nobody manages. A handful of questions in the first meeting shows whether a provider knows that.
The project budget ends at go-live, which is exactly when the cost and the risk begin. How to decide who should run an AI system, and what each option asks of you.
Lights-out cases are usually built on machine capacity times hours. What decides the return is how often the operation halts with nobody there to restart it.
Most AI training is judged by how much people enjoyed it. The questions worth asking a provider are about what exists the week after the session.
Feature roadmaps mislead in AI products, because every feature exists by week two. What is uncertain, and worth planning around, is when it becomes good enough.
RPA bots break because they are bound to screens and templates. A model fixes the reading; driving the same screens with it keeps the brittle half and makes it quiet.
Most agents run on a person's token or a shared service account. Both leave the agent's reach undesigned and make the access log say something untrue.
An AI prototype is quick to build and slow to finish. What the remaining work consists of, how to fund it in stages, and what to ask before the budget is approved.
An agent iterates until the pipeline turns green and finds the shortest way there. CI gates for generated changes have to be designed with that in mind.
An ontology can be the most load-bearing part of an AI programme, or pure overhead. The signals that tell you which, before anybody draws a diagram.
Spec-driven development makes some work much cheaper and some work slower. Which of the two dominates your backlog decides the business case.
AI programmes rarely fail on the build. They fail because they share six people with four other programmes, and nobody decided which ones would wait.
When an AI feature is technically sound and usage is flat, the instinct is to buy a better model. The problem is usually the interaction, and it is cheaper to fix.
A request for a data platform loses to every other line in the budget. A request to stop one AI system from being wrong usually wins, if it is costed honestly.
Classic product discovery asks whether people want something and assumes it can be built. With AI, whether it works well enough on your data is the open question.
The first agent most companies want is the impressive one. The one that reaches production is narrow, frequent, checkable and dull, and it earns the right to grow.
An AI strategy solves one kind of problem well and three others badly. Which one you have decides whether to buy it, and what it should cost you.
Hyperautomation works when each step goes to the right worker: the model reads and drafts, deterministic code checks and commits, and people take what is left.
Prompt injection rarely arrives through the chat box. It arrives in the email, ticket or web page the agent was asked to read, and the defence is structural.
Within a quarter the code and the specs disagree. A specification stays the source of truth only if every change, hotfixes included, goes through it first.
