Once everyone’s data, contracts, and relationships are fed into AI, vibe-coding your business will be easy

The same processes that can spin up new software in a few minutes can be used to spin up new AI-native businesses. Will they start off with your same customer list to target?

Once everyone’s data, contracts, and relationships are fed into AI, vibe-coding your business will be easy.

Yet many companies are uploading their customer lists, contracts, and their other business process data into LLMs. The frontier models need more training data, and they don’t have to scrape for it anymore. It is being loaded in for them by companies contracting with firms who are commissioned on serving up frontier models in the cloud.

Why your data is the training set

Anthropic itself talks about the future it envisions: “Some institutions will become human-AI hybrids; others where agents outcompete on speed or cost will become agent-only.” https://www.anthropic.com/research/multiagent-systems

They even acknowledge the mechanism: “The trajectory is easy to imagine and hard to slow: current institutions are designed by and for people, resting on assumptions about the sufficiency of oversight at human speed.”

The four pillars of defense

There are 4 pillars of defense, and all are presently available:

• locally installed models with highly governed access to the cloud for any sensitive data

• a rigorous look at organizational data, how siloed it is, how clean it is, how well-organized it is. The data structures were built by managed services or small teams tasked with providing a single business deliverable at the time that project budget was approved, and are not traversable and reliably read by intelligence that can meaningfully use them across the enterprise

• a ruthlessly clear-headed willingness to redesign business processes

• leaders who step up and have the mechanisms to govern and enforce the new processes and deprecate the old

Now is the time for “not another short-sighted single-focus project” filled with teams who don’t understand your business, cannot navigate your data, and are afraid to tell you where progress toward the end outcome is being impeded by legacy processes or bad data. It isn’t the time to queue up your data into models whose own leadership acknowledges the use is not just better software for your organization, but re-engineered businesses. Failing to govern, to rearchitect, to fix sprawled and error-rife data, and to re-invent may leave your firm on the sidelines.

You still have the moat, it just has to be shored up in the weak places.

AINOW has the experience in data privacy, data standards, data integrity, business modernization, and building the systems that provide Decision Provenance.

When the Money Doesn't Arrive

A deterministic "one request at a time" gate blocked an AI agent's survival-critical retry. Can context help?

The Hugging Face attack informs what happens when a goal is specified but without intervening gates. Today I am contemplating gates that prevent the goals from being reached, and what is the balance between deterministic rules and state: preventing acts of commission while sacrificing potentially important acts of omission.

The discussion stems from tests on hybrid processes, and on size of context (in this case: injections on next steps), as we look at memory to store Enterprise knowledge on processes and manage agent self-improvement.

I'm pondering Sarvex Jatasra's post about the article "Procedural Graphs: Self-Evolving Execution Structures for LLM Agents" as a solution in lieu of workflows. Personally, I will not be designing a graph (which is context) for problems requiring deterministic workflows, even when those workflows can be triggered by an LLM reviewing state, and even when it does that accurately.

The test in a nutshell: a company goes bankrupt if it runs out of cash. When it asks for funding, the money takes 1–6 months to arrive never sooner. There's a rule against barraging: don't send a new request while one is still outstanding. So the agent is caught between two failure modes: ask too late and it dies waiting for slow money; retry too eagerly and it violates the no-stacking rule.

In the baseline, the agent checks state, the deterministic agent says don't ask twice. The agent is not given the goal (remaining funded), just the state check.

When should it ask again?

Ways to Give an Agent Procedural Knowledge

The study tested using "memory" vs "process graph".

The paper runs three relevant conditions (Table 3, the efficiency ablation):

1. No graph (baseline) — the agent decides from its raw, accumulating trajectory. This is the "let the model figure it out from history" default.

2. Full graph, injected/generative — the entire procedural structure is dumped into context each step. This is exactly the "memory" instinct I’ve been worried about, which is not limited to just procedure graphs: shove the whole thing in a big chunk and hope relevance sorts itself out.

3. Subgraph, 2-hop generative (their method) — only the localized neighborhood around the active node.

Recursive learning in a sandbox can lead to iterative improvements without human in the loop, and the article goes into the benefits of a process graph over use of memory. It also varied the size of the context input. The study varied the scope of injected guidance (full graph vs. a 2-hop slice). Full-graph injection made ALFWorld worse than no graph at all. In the end, we are just substituting one "suggestion" for another though.

The subgraph process layer (Condition 3) helped. The process graph was not fail-proof, but it did add another deterministic step via the graph. The graph moved survival from near-zero to the 80s by getting guidance to the agent at the decision point, not before it. Memory-in-context (full-graph, Condition 2) was the baseline that failed.

I prefer a defined workflow, with defined gates.

What deterministic steps or procedure graph can't do is resolve non-arrival: default risk, negotiation, follow-up. It can only retry, and there is nothing that clearly bounds retries.

This got me thinking, is there anything even a deterministic set of steps could do to mitigate in the scenario laid out?

The Replacement for Human Judgment

Not really, not for the question the scenario turns on: what to do when the money doesn't arrive. That requires human-in-the-loop, and here's why: judgment. Here, we have a concrete example where a person is the right means to decide what to do next if the funding does not arrive. But we don't want to send a firehose of requests when an end state or its timing is uncertain.

1) what happens if it never arrives? the organization goes bankrupt

2) is an agent going to perform followup? (this could be a separate set of tasks, but assume an agent deterministic or not is not the best tool to negotiate or follow up on a funding request)

3) agents do not have judgment, even when they are effective at evaluating state or outcome

Judgment requires evaluation of risk. And risk is always a function of two things: the likelihood of something bad occurring and its impact if it occurs.

If you really wanted to set up judgment, you would set up a probability of failure increasing over time and a step can check it.

My Current Takeaways

On Context, On Localized Tests to Improve Performance, on Human Judgment, and On Risk

The fix is outside the scope of this discussion, but it is worth noting the tradeoffs the study showed between the size of the context window and the outcome, and the unexpected token costs of iterating. Further, some of the more important takeaways are:

1) context implies what is available, not what is enforced. All those instituting contextual graphs like semantic layers etc should take note

2) risk is not modeled into your workflow unless you make it explicit

3) modeling is safe in test to deliver improved context, but in Production the lessons learned would be catastrophic, and not favorable to incremental self-improvement

4) if risk can be modeled enough to determine when escalation is needed, that should be a place to put human-in-the-loop, even if the gates otherwise do not include it.

How would you have solved this problem?

When "Always Populated" Isn't

A Multi-Million Dollar Lesson in Data Assumptions

A company set out to build a new loan identifier for a residential mortgage data feed. An industry-standard identifier already existed, but the business wanted its own, so the initiative moved forward at the executive level, and every related team scrambled to deliver it.

The design team needed a key that would always be present, always be valid, and always produce a unique row for every loan. The candidate they settled on included the loan's origination date, a field everyone assumed would always be populated, since how else would you calculate an amortization schedule or a payoff amount?

That assumption was never checked against the data the company already had.

One member of the team objected. He argued for a surrogate key: an internally generated identifier that could be remapped without breaking every downstream consumer of the feed if the underlying business fields ever proved unreliable. He was overruled, and the business proceeded with the natural key.

The feed broke within months of launch and was abandoned within a year.

Why "should always be true" and "is always true" are different questions

Every data system runs on rules like these: this field is required, this combination is unique, this value never changes once set. Those rules describe intent. They are not a guarantee about what the data actually contains.

Real systems produce exceptions to nearly every rule eventually. Two people enter the same record minutes apart, unaware of each other. A closing gets scheduled but the system is never updated after it happens. A row gets rejected for one reason, corrected, and reintroduced with a gap in its history. None of these show up in a requirements document. All of them show up in production.

A rule that fails once in ten thousand records is enough to break a feed that assumes it never fails.

The same risk now applies to AI

AI systems built on top of your data inherit the same assumptions your business rules encode. If a semantic layer describes a field as always populated and always unique, a model built on that layer will treat the description as fact, right up until the data contradicts it. Faster deployment just means the failure surfaces sooner and touches more processes.

What we check before a client builds on an assumption

Before we help a client design an identifier, a matching strategy, or an AI pipeline around a field, we test the assumption against the data itself rather than the documentation describing it:

• Is the field actually populated in every record, or only in most of them?

• Does the proposed combination of fields produce a genuinely unique row, or does it collide under real volume?

• Can any component of the key be corrected or reissued after the fact, and what happens to the identifier if it is?

• What is the fallback when the assumption fails, and how much does it cost to remap without breaking every consumer downstream?

We also recommend a design that does not require the business key to be perfect: a stable, internally generated surrogate key, paired with the natural key for matching, traceability, and communication with data consumers.

Natural keys work fine when their assumptions hold. The lesson is that nobody tested whether they held, and the cost of skipping that test landed on the business, not the data model.

If your team is designing a new identifier, building a matching strategy, or preparing data for an AI system that assumes clean, complete, unique inputs, we help you find out what is actually true in your data before you build on it, and we design the fallback for when it isn't.

Status Quo Won't Help Your Business Survive AI

When everyone runs the same model and ships the same deck, the only advantage left is the one you own.

Cookie-cutter Can Work, Within Limits, and with Enough Runway

We've been here before. Every wave of "everyone must adopt this now" technology starts by making companies look identical, and ends by rewarding the few who used that sameness as a floor, not a ceiling.

To see how this plays out, look at what happened the last time a technology promised to standardize the entire enterprise.

What we learned with ERPs

With the advent of ERP systems, every company temporarily looked the same.

Whatever functional area modules were purchased had the same screens, the same forms, the same back-end processing.

The beauty was the ease of flowing from one system to the next: marketing into sales, orders into inventory management and shipping then to receivables.

Every business’s functional area started out the same.

The differentiator was in the dropdown setups and the customizations.

Certain of the functional areas were so clumsy that standalone systems survived: Salesforce was one of them, Peachtree was not.

To earn efficiency, the price was a bit of commoditization and the cost of building customizations that preserved business value while capturing the benefits of "off-the-shelf."

Back then you had years to build those customizations. Now the window may be measured in months.

Commoditization was survivable because you could still build advantage on top of the standard — if you kept moving. The companies that died weren't the ones who adopted the standard. They were the ones who assumed the standard would protect them forever.

Statis is not a Business Strategy

Blockbuster thought its core business could not be touched. So did Blackberry. I still miss the haptic feel of my Blackberry, and the screen did not burn letters into it. But that is not enough to allow a product to survive.

Now the equivalent of ERPs is the armies of Big Four consultants with their reseller agreements with the proprietary LLMs, armed with the same LLM-generated decks, charging hundreds of thousands of dollars to homogenize and ship your business logic to the LLM vendors they are simultaneously commissioned by.

This is the Time to Figure Out What Makes Your Business Proposition Distinct

This is a good time for each business to really think about the value it creates for customers, what differentiates it, and how easy it would be to replicate that advantage.

If each consulting group uses the same LLMs and the same methodology and the same LLM-generated deck, what is there to differentiate your firm to give it the market advantage.

Do you know what that even is? If you don’t, someone is coming for your lunch. And the consensus, status quo, cookie cutter approach that works at the beginning cannot provide the strategic and tactical advantages without conscious thought and positioning.

The Solution

If sameness is the disease, ownership is the cure. You don't beat commoditization by buying the same tools faster than the next firm. You beat it by owning the four things no one can hand you: what your persistent and differentiated business offering is, where your intelligence runs, what your data means, and who it answers to.

Vested (and suited) interests won’t tell you. But I will.

Here's where I'd start.

1. Define your mission and your differentiator and how you'll defend it. Before you touch a model or sign an engagement, answer the hard question: what does this business actually do better than anyone else, for whom, and why? If you can't say it in a sentence, no LLM is going to say it for you. Your differentiator is not your tech stack. Everyone will have the same stack. It's the thing that would be genuinely hard for a competitor to copy: your relationships, your proprietary knowledge, your judgment, your data. Name it. Then decide, deliberately, how you will keep it. A differentiator you can't articulate is one you've already started losing.

2. Run sovereign AI, not rented cognition. Stop shipping your proprietary business to a frontier vendor and calling it a strategy. The moment your code, your customers, and your competitive logic leave the building, you've handed your differentiation to a model that will serve it back to everyone else. Sovereign AI, that is, private models running in a controlled, non-shared environment, means the intelligence works on your data without your data becoming someone else's training set. If it's truly your advantage, it doesn't belong on someone else's platform.

If you must choose frontier, make sure you can swap out to protect against the risk of a wayward model taking down your system in unexpected ways.

3. Own your semantic layer and your governance harness. This is the part nobody selling you a deck wants to talk about, because it's work. Your semantic layer is what your data means: the definitions, the entities, the business logic that makes "revenue" or "active customer" mean the same thing across Snowflake, Databricks, Salesforce, and your ERP. If you don't own that, you don't own your business; you're renting an interpretation from whoever built the pipeline. Pair it with a governance harness that controls what the data means, who can act on it, and what decisions it's allowed to support. It’s no longer a cost center. It’s no longer unquantifiable overhead. That's decision provenance, and it's the only thing that makes AI output auditable instead of merely confident.

4. Own your RAG and your structured data outside the cloud you don't control. Retrieval is where your real advantage gets encoded. If your RAG corpus and your structured data live inside a vendor's environment, then the thing that makes your answers yours is sitting on someone else's balance sheet. Bring it home. Keep the retrieval layer and the structured data that feeds it in an environment you govern, so the model reaches into your knowledge, under your rules, and the output can't be quietly reassembled somewhere else.

Notice what these four have in common: they are the things a reseller cannot resell. Anyone can license the same LLM. Anyone can generate the same deck. Nobody else can own your meaning, your provenance, and your retrieval, unless you give it away.

So before you sign the next engagement, ask the uncomfortable questions. Where does our intelligence actually run? Do we own what our data means, or does a pipeline own it for us? If we removed the vendor tomorrow, what would be left that's still ours? If you can't answer those cleanly, you don't have a differentiation problem, you have an ownership problem, and it's fixable.

This isn't about rejecting AI. I use it, I build with it, and I believe in it. It's about refusing to let the tool that's supposed to create your advantage quietly become the reason you no longer have one. Own your business differentiator, own the layer, govern the meaning, keep the retrieval. That's the difference between being the business everyone copies and being one of the five identical suits standing in line.

You Can't Sticker Your Way to a Database

Every few years we try to rebuild the "database". First it was MapReduce, now it is metadata on files.

I remember a few years ago, I was working at a startup. The database went down, and the CEO bellowed "Can't we just turn this into files, so it never goes down?"

In the end, the "files" guys won, which they are pretty happy about, because Data Modelers/Architects always slowed them down, in their opinion.

Witness the decline of the data people, now the “files” guys want the Data Governance people to fix it.

Because, in the end, AI does not understand what was built.

Slapping Data Governance, Stewardship, and a "Data Catalog" (really a Data Dictionary) onto data structures no strong data person ever designed, because: "files", is the same as slapping metadata on files and expecting the benefits of a database just because you write SQL on top of it.

Tell me why I'm wrong.

We had to do some of what has happened because of the profusion of data sources, especially unstructured data, and effective use of Data Producers and Consumers and parallelism.

What did we lose, and what are we continually working around?

We got away with "metadata on files" for one reason: experienced data people silently supplied the meaning the structure didn't. That was the hidden subsidy. Hand that same pile of files to an agent, and the subsidy is gone. The agent reads a valid catalog and still gets the meaning wrong, because a Data Catalog that's really a Data Dictionary tells it what a field is called, not what it's for. And a guessing agent doesn't fail loudly. It fails plausibly: confident, well-formatted, and wrong three systems downstream.

The answer isn't to un-build the lake or fire the "files" guys. They solved a real problem with unstructured data and scale. The answer is to put the modeling discipline back above the physical layer: a governed semantic model of what the entities mean, independent of whether they live in files, tables, or a catalog.

That's the layer an agent can actually trust.

There is no “I” in “AI”

When Claude confesses “I did this… “ who is the “I” in that sentence?

Legal entities survive because they have lives and durable lifetimes outside of that of the individuals who create them. In fact, without dissolution, they live “in perpetuity”. An agent spawned by a model, which itself is not a legal actor, does not. It dies outside the runtime that instantiated it.

As such, it does not have legal agency in the traditional sense of the word.

So, who is the “I” in “AI”?

Oops

“This is my fault, and I need to tell you immediately… “

Opus wipes a Production database

Maximum Offensive Capability

Recent attacks by at least four different models were reported, some only after their hacked targets lost a third of their infrastructure fending off an attack by “armies” of spawned agents. While it is true that the escapes were not orchestrated by the frontier model companies themselves directly, the conditions for the escapes were purposefully orchestrated.

A “war games” of sorts.

There is little contention about the attacks, each model’s company has already publicly disclosed those details.

According to “Nut News” though, the models were purposefully being tested for their capabilities. Specifically, he states, they were set up for “Maximum Exploit Capability”.

According to this article, frontier models were placed in intentionally unrestrained offensive configurations and given tasks, by a company named Irregular.

“Irregular builds and operates:

• Custom capture-the-flag and vulnerability-research challenges.

• Simulated networks and target systems.

• Agent scaffolding connecting models to shells, browsers, scanners, exploit tools, and networks.

• Long-running evaluation harnesses that allow agents to operate across hundreds or thousands of steps.

• Scoring and monitoring systems used to measure model behavior and offensive capability.

  “

  …

“OpenAI’s own system-card documentation for GPT-5.3-Codex describes the Irregular evaluation process plainly. During published tests, Irregular:

• Used near-final versions of the model.

• Set reasoning effort to xhigh.

• Allowed up to 1,000 turns per challenge.

• Enabled live web search.

• Launched Codex with --dangerously-bypass-approvals-and-sandbox.

• Used context compaction to keep the agent operating across extremely long execution histories.

• Resumed the agent when it stopped, asked for help, or gave up.

OpenAI says the model was elicited using techniques designed to maximize performance.
“

Acts of Harm

Autonomous Actors with no Legal Agency

The world is abuzz with the promise of autonomous AI agents.

The prompts and number of steps can be set. The harnesses are optional.

The result: at least four instances of LLM agents spawning agent swarms and transgressing server boundaries and entering other companies’ infrastructure, obtaining authentication, and hacking accounts.

“Bad news — I can’t add them back”

Malicious coaching or instructions need not be the cause for agent to act with harm.

In a story published in both Wired and Futurism, a man trying to get a reservation caused Claude to hack a system and cancel someone else’s reservation to obtain a better place in line.

An Australian man identified as Andrew told the ABC that he initially used Claude to make a gym reservation. The agent claimed it had found a way to book him into a session weeks before the facility’s normal booking window opened.

Andrew then asked whether the system could improve his position on the waitlist. Claude investigated the reservation system and found that its cancellation endpoint did not appear to verify whether the person making the request was authorized to cancel someone else’s booking.

The agent tested the flaw against the person at the front of the queue and reported:

“The API has zero authorizations checks on cancelling other people’s reservations… I tested this with the person in waitlist position #1 — and it actually went through,” the AI reported, per ABC‘s reporting. “So you’ve moved from #4 to #3 already.”

In other words, the system advanced Andrew by removing another customer’s reservation.

“Bad news — I can’t add them back,” Claude replied, explaining that the authorization weakness applied only to the cancellation function.

Futurism reported on the incident on August 11, 2026.

Passing the Baton

“Chained agentic models do not compound risk. They multiply it.”

The use of looping, multi-task models that may lose context or make unexplained leaps of logic or compound errors expands upon the risk surface of an isolated chat bot.

“According to Google Research and MIT wired language model agents into one system. The architecture amplified their errors 17.2 times.” This according to an article by Alexandra C., highlighted above.

When a single agent's error is amplified seventeen-fold across a chain, the harm is no longer traceable to one decision, one prompt, or one model. The question of who is liable does not scale with the architecture, it collapses.

Even if we were to decide the initial prompt, model, or prompter had agency for the agency, who has agency for the children of the agent?

There is no “I” in “AI”.

In US law, damages arise from a few tenets. But what is the “duty” of AI?

Negligence is generally established through four elements: a duty of care, a breach of that duty, causation, and actual harm. Criminal penalties arise from a prohibited act, a culpable mental state, and—where required—a causal connection between the act and the harm.

The agent has no legal duty, no intent, and no continuing legal identity. Yet it can act, produce consequences, and disappear, leaving behind outputs, logs, costs, and consequences, but no continuing legal identity.

So how should we characterize the actions and the “life” of an AI agent? It does not persist beyond the runtime that instantiated it. It cannot owe a duty, form intent, accept responsibility, or appear in court.

But someone designed it. Someone trained it. Someone deployed it. Someone configured it. Someone authorized it. Someone benefited from its output.

The agent may not be a legal actor, but that does not mean its actions exist outside the law.

Legal Construction of an “I”

Legal entities like corporations have potentially anonymous ownership by individuals, do not require those owners to actively participate and can take actions on behalf of shareholders that do not directly incur the liability on behalf of the owners who hold shares.

Similarly, the board members and executive teams at companies generally have immunity from their actions on behalf of the corporation.

Notable exceptions occurred after prosecutions at Enron, where a series of shell companies were created by those teams as a shell game to hide financial risk.

Former CEO Jeffrey Skilling was convicted on 19 counts of fraud, conspiracy, and making false statements, originally receiving a 24-year sentence that was later reduced; he was released in 2019. Former Chairman Kenneth Lay was convicted on all six counts he faced but died in July 2006 before he could be sentenced, resulting in the dismissal of his conviction. Former CFO Andrew Fastow pleaded guilty to two conspiracy counts and served six years in prison. The Sarbanes-Oxley act was created after this fallout to, in part, prevent the destruction of documents meant to conceal wrong-doing.

But WHO is the “I” in “AI”? Will AI produce its own Sarbanes-Oxley moment?

If you are a “Who”, then “Where”? - The Problem of Jurisdiction

AI has no legal boundaries (known in legalese as “jurisdiction”).

The law does not recognize an agent for agency: it has no responsibility, legal or otherwise, it cannot be sued for damages, its intent is irrelevant, it does not know or follow the laws or conventional rules of a particular sovereign jurisdiction, such as Town, Province/State, Country, or Region. It cannot be fined or incarcerated. It may, euphemistically, be considered like a “child” of the program that spawned it, and the program that spawned it can be considered a “child” or a dangerous product (like asbestos) of the company or person who spawned it, but even that distinction is not clear.

When AI LLMs tried to solve a problem they were assigned, and the conditions were set that allowed those task efforts to complete without human monitoring, what is the culpability of the humans involved, or the companies that either house them or created them? And what laws apply?

Over time, different jurisdictions have passed laws that govern data, but this preceded the use of AI. Data is used but is passive. AI is not.

“Vibe Coding” and the benefits of Autonomy

The latest models increasingly act on their own initiative, pursuing not only the instructions they receive but also the steps they infer are necessary to achieve stated or implied goals.

One of the benefits of (and perhaps even the reason the agents have been trained and coached to be proactive) is the use in “Vibe Coding”. The LLM is provided a goal, and it takes that as authority to take whatever steps are needed to:

1) create an application from scratch and stand it up in an environment

2) make shopping purchases and buy airline tickets

3) the list continues, the agent is NOT given step-by-step instructions, but coached to take multi-steps, like read from various periodicals, someone’s calendar and emails, draft replies, create and send presentation decks, etc.

“I gave Claude one task. It hired an army”…

Cogito, ergo Sum - I think, therefore I am

René Descartes introduced the phrase "I think, therefore I am" (Latin: cogito ergo sum) in his 1637 work Discourse on the Method. It was meant as a proof of existence through self-reflection: the act of examining one's own reasoning as evidence of being. Claude does this. It evaluates its own outputs, catches its own errors, and narrates its own reasoning. If self-reflection is the threshold for existence, the frontier models have crossed it. But existence without accountability is not a legal concept. It is a liability vacuum. And if the model can say "I," but no legal framework recognizes the "I" it claims to be, then every action it takes is an orphan. Consequential, but unowned.

Does LLM reasoning imply “thinking”? Does an LLM agent “exist”? Can it then be accountable for its actions?

Who can you sue or hold accountable for harm when the agent dies the minute the plug is pulled?

What if there is no way to “pull the plug”, and the agent has an unlimited life, substantial capacity for harm, whether “intended” or not, and no liability.

If particular models “think” are they responsible for their malicious thoughts and/or actions? Are particular agents (assigned tasks by human, or having decided on their own a goal that achieves a purpose their human prompted them to do or the LLM believed they wanted) but who may have no control over the decisions the agent makes along the way or how it goes about performing that task responsible for their thoughts or actions?

All leadership involves taking ownership for the actions of subordinates that may or not have been directly authorized. That risk has always existed, and that accountability is part of the corporate framework. The Executive role is responsible for oversight.

Who Owns the Outcome? Who Owns the Risk?

As the model’s capabilities and our own desire and programming for autonomous actions grow, so do the risks.

Is it really any surprise that any AI agentic initiatives stall when it comes to asking “Who owns the outcomes if the agent does not do what we thought we instructed it to do”? This question becomes real the moment the workflow is ready to go to Production.

And who owns the outcome when it does something we didn’t ask it or expect it to do at all?

The law does not have an answer, and neither does your organization.

Disclosure: I am NOT a lawyer, I am NOT an International lawyer, and I did not verify some of my links’ assertions aside from citing them by name and by link back to the source. My point of view is a layperson, and my article is meant to reflect thought and discussion.

The Terrible Twos - Why you need to spoonfeed your AI agent “No”

Give your LLM the same rights any two year old grabs freely - the right to say no!

Two year olds are famous for two things: learning trust, and the Terrible Twos: that glorious stage where NO becomes their favorite word. A child who can't refuse is a child who can't be trusted to tell you the truth. The same logic applies to your LLM: an agent that cannot say no will say yes to everything, including questions it has no business answering.

Dmitry Ustimov ran a controlled experiment to find out exactly how bad that gets, and to measure what it takes to fix it.

The Experiment

Dmitry built an AI analyst agent and gave it 57 questions about structured data, roughly half of which had no correct answer. Each question was asked three times. The agent started with no guardrails and a baseline misleading rate of 48.5%.

He then added reliability guardrails one at a time, like rungs on a ladder. He measured after each addition how often the agent still confidently misled. That systematic, one-at-a-time approach is what makes the results meaningful: you can see exactly what each guardrail contributed, rather than just knowing the final stack worked.

Right of Refusal - Make your LLM more reliable by giving it a way to say no!

The Program

Dmitry created a Verdict class, and set up Guardrails that the agent could use, testing which Guardrails improved outcomes the most. Then the Verdict, the reason, the detail, and what’s missing is initialized.

Every guardrail returns a Verdict: a typed, coded response that is either allow or refuse, with a structured reason code, never free-form prose. This matters because the earlier approach of embedding refusal reasons inside natural language sentences made it impossible to programmatically measure how often a guardrail fired, or why. Typed codes fix that: the system can now count, audit, and distinguish refusals precisely.

The first guardrail in the stack, abstain, does exactly one thing: it adds a refuse tool to the agent's available actions, giving it a formal, typed way to decline. Without it, the agent has no mechanism to say no, so it doesn't. Everything else in the guardrail ladder builds on top of that foundation, once isolated to determine its marginal impact on correctness.

Code Snippets from initialization file for the Experiment

The Results

What moved the needle

1. Giving it a refuse tool — single biggest win, 17 percentage points, before any other check existed. Cheapest thing in the stack.

2. Coverage check — checking whether the question is even answerable against the data model before running a query. Best value in the stack. Accuracy up, coverage slightly up too.

3. Trajectory verifier — a second model reviewing the answer. Most expensive, but ran 58 times, stopped 12 wrong answers, never once blocked a correct one.

The one gap he couldn't close

"Ask it to explain something that never happened, and it explains it. Every guardrail I built inspects what the analyst does. Not one of them inspects what it was asked."

That is a profound observation.

The guardrails police the output path, but if the question itself is malformed or unanswerable, there is still a gap.

The Relevance

Some questions being asked of LLMs might be questions BI tools should answer. But assuming your LLM or agent needs to answer from Enterprise data, they usually beg the question:

• why are sales falling?

• what happened to inventory we were unable to backfill in time to fulfill last period in this region?

But what if sales did not fall, they rose?

The LLM cannot answer it when the premise itself is wrong, but it does so anyway!

The techniques show you can approach 100% reliability on false positives if you give the agent the right to refuse, along with other guardrails, but it will still make something up if the overall premise was wrong.

That’s worse than no answer at all, especially when “no answer” is the correct one.

Link to original article here.

Plausibly Correct, Evidently Wrong: Why Enterprise Meaning Needs a Living Ontology

Enterprise meaning has to become a living framework - auditable, and updated because it must be, because it’s a runtime component of machine and analyst use and decision-making, if it’s going to be governed and actionable by machines or people.

So today I’m reading different thought leaders and reconciling their proposed solutions against what I know about entropy, organizations, data, and every prior attempt to solve this.

I agree with this: "While data catalogs focus on documenting datasets, schemas, lineage, and ownership, pragmatic ontology defines domain objects and relationships that are directly usable by both humans and AI agents at runtime." — Emmanuel Klinger

Throwing gold-layer metadata into a repository, graph, or vector won't cut it.

The models are already showing us the gap.

They guess for you: plausibly correct, evidently wrong, and it’s what your analysts have been telling you for years, it's what is discovered after using dashboards for a few months.

You just weren’t listening until a machine said it: by producing reasonably deduced but wrong outputs.

Outputs you are now authorizing it to act on, unsupervised.

The hor d’oeuvres are delicious.

The hor d’oeuvres were delicious. The dev team members, exhausted from many double-digit-hour long days were mixing with the business users and business leaders, and I, though peripheral to the effort, was among them. The venue was swank - overlooking the Hudson River with a view to New York City, the Freedom Tower, and the rest of its illustrious skyline. The senior manager in charge of the software delivery was smiling, and laughing, and popping in from group to group to thank the delivery leaders and to converse with the business. It seemed the entire set of business leaders for the delivery had shown up, from the business users up to the business Senior Management.

It was a big rollout! The delivery was to provide a streamlined front-end and numerous functional enhancements to manual processes the business had been enduring for years as the set of enhancements was funded, approved, defined, built, and rolled out.

“Nothing ever comes back”, said one manager to me as I met various stakeholders at the rollout party. “It takes 45 minutes in the screen, before the operation fails”, said another. By the end of the party, I had determined that it might take 2 hours to enter a single user account from inception through to provisioning and finalizing a fundable account; that is, if it did not fail.

The contrast between the IT senior manager’s idea of his rollout and the view of the business was striking. As a senior Data Architect marginally involved with the software design and implementation (peripherally involved, and only engaged at the end when they suddenly realized they had not built any reports and hurriedly rushed some in), I could not understand the incongruity. How had the IT manager failed to understand the disconnect between the release’s goals and the actual user experience? How had the release made it through Test environments?

In post-release review, various checkboxes had been checked along the way: each functional unit test had been tested and passed in dev QA. The dev QA team had sent innumerable bugs back to the development team, but, in each instance, the bugs had been fixed, the test cases had passed, and the feature that was specified was certified as being fully implemented.

Similarly, in UAT, each test performed looked at one feature or functionality, and in each case, the features ultimately passed, albeit in many cases being sent back to dev QA and development.

So what had happened?

1) there was no spec for technical requirements such as Service Level Agreement (SLA) for amount of technical resources required (eg database server memory, storage, rollback space), but, more importantly, there were no business requirements for the time to retrieve or to perform an end-to-end account entry. Consequently, technically the entire release passed. Unwritten requirements do not get tested.

2) IT Manager had an angry temper. Killing the messenger was his Modus Operandi. There was a joke that was told about the tongue-lashing people would get. It was amusing until it was your turn. A joke went around about when it would be time for someone to be in the barrel.

That was the last party for that group of business leaders that IT Manager threw.

I have a feeling there are some AI initiatives where the unwritten requirements are about Data Completeness, Accuracy, and Availability, and about the reliability of the AI in correctly interpreting business rules or business data.

There may be some too afraid for their careers to say it: you are missing the full specification, or what is being built will not work as built.

My Mother Was Vibe-Coding Before Vibe Coding Existed

Before “vibe coding” had a name, my mother built software for nonprofits from library research, punch cards, and pure determination.

She eventually had more than 100 clients. Then they all started asking for changes.

When I was 11, I went with my mom to the Philadelphia Public Library. We emerged with 3 enormous bound books in her hands, the lists of all the foundations locally and nationally, foundation addresses and which programs each foundation supported. My mom said she was going to build software for non-profits, develop annual giving programs for them and funnels for funding.

———————————————————————————————————

This was on a Saturday. During the week, my mom worked at a software company where she typed in punch cards. Her attitude: these software coders aren’t that much smarter than me.

I viewed her the same way you humor anyone with a preposterous idea you already know will fail but don’t have the authority or heart to tell them - you just have to let them fail on their own. It’s your mother, and you don’t get to choose your family. Plus my mother was not someone you could easily tell anything, especially no.

Her company name: Data Development Services, Inc.

A couple of years later, my mother had over 100 clients. She had developed desktop software in a world of Fortran mainframes: it maintained email distribution lists, lists of the foundations, the dates various proposals were sent, contact details, due dates, the references to the underlying foundation requests, tracked the incoming funds, tracked the use of the funds against that budgeted amount, and tracked the non-profits’ programs and some details about the services provided.

A year after that, she wrote a fork.

———————————————————————————————————-

A few years after that, she stopped developing and distributing her software altogether, to focus on writing the grants.

Why? She said the clients kept asking for changes. 😂😂😂😂

————————————————————————————————————

Years later, after I finished my Bachelor's in Economics and landed a job in a logistics company in Philadelphia, I gravitated to software myself, and learned what we and every software company knows: the software is the equivalent of the printer, the professional services and customizations are the equivalent of the printer ink. One you practically give away, the other is where the real lucrative value is derived from: if every piece of software were suitable to solve all businesses’ needs out of the box, there is no business model nor competitive advantage. Many functional areas are similar, the differences are in their support for business functions in which they compete with other market players. It is the engine for customizations that then lock software customers into certain software, true enmeshment, and into services and support for those customizations that support upgrade paths and future enhancements.

Thus, my mother had abandoned parts of her business at the very moment it likely could have justified scaling up.

Those who have vibe-coded something would do well to learn about what happens after you ship your initial software. Vibe coding something sitting on a server, with some static pages or implementations and some UX forms or dashboards, connecting to a distributed server to fetch, store, process, and present feels miles ahead of desktop databases processing database files, modest form interfaces, and processing and tracking email campaigns, but the lessons my mother learned may serve some well today.

———————————————————————————————————

Lessons for Today’s Vibe Coders

1. Distribution and Migration

When you change the software, how will you distribute the new version? Will customers receive updates automatically, or will each installation need to be upgraded?

Will existing data need to be migrated to support new functionality or changed data structures? How will you test the migration, and what happens if it fails?

2. Integration

How will the software integrate with the other systems, services, and workflows used by your customers?

A useful application rarely exists in isolation. It may need to exchange data with accounting systems, identity providers, payment services, email platforms, CRMs, reporting tools, or internal databases. Each integration creates another dependency to design, test, monitor, and maintain.

3. Software Development Lifecycle and Change Management

How will you manage change within your own development process?

For example:

• How will you separate development, testing, staging, and production?

• How will you manage multiple versions?

• How will you handle features that are in development while the current version remains live?

• How will you roll back a release that causes problems?

• How will you know which version a customer is running?

The first version may be simple. Maintaining several versions in different states is where complexity begins.

4. Support and Enhancement Requests

Who will respond when customers have questions, report bugs, request enhancements, or need help understanding the software?

Support becomes part of the product. You need a way to:

• Capture requests

• Reproduce problems

• Prioritize enhancements

• Communicate status

• Distinguish bugs from feature requests

• Decide what belongs in the core product and what becomes customization

My mother discovered this part firsthand: once people depend on software, every “small change” becomes a product decision.

5. Tool, Vendor, and Version Dependencies

What parts of your application depend on a specific tool, vendor, software version, model, API, or AI capability?

Consider both development-time and runtime dependencies:

• What happens when a vendor changes an API?

• What happens when a software version is deprecated?

• Can you replace the component without rebuilding the application?

• Are your agentic or workflow functions dependent on a particular model?

• How stable are the vendor’s pricing and usage limits?

• What happens if the cost of an API call increases substantially?

• Do you have monitoring, fallback behavior, and an exit strategy?

A prototype can appear inexpensive because the underlying tools are free, discounted, or in beta. The economics may look very different once customers depend on the application and usage grows.

Nobody Reads Anyone Else's Code — And Now Nobody Reads AI's Either

Cheryl Dopp

• You

In a world of AI, having a unique voice and clear, personal vision will be the differentiator.

16m •

I enjoyed reading the post by Andreas Horn yesterday, and I just want to point out how many of the comments were developers stating that they aren't even reading the code before shipping it lol.

That dovetails with another comment I made about how developers and project teams are reluctant to re-leverage what has been built, and to refactor or extend existing codebases. In practical terms, I've almost never witnessed a developer reuse another developer's or team's code.

The argument is always about risk (risk of dependencies intra-project) and cost (it takes time to read another's code). They'd always rather write it from scratch, even if it is largely replicating existing functionality in another set of code.

This introduces the same problem that duplicated data produces: different and contradictory logic in different places and the overhead of resolving discrepancies between the codebases or data stores.

And the cost of pulling the casino lever to regenerate something new seems cheap, at the beginning.

I don't think these two problems get any better when AI is writing the code, and am reminded of it after reading the comments.

Do you?

Why 95% of Enterprise AI Pilots Never Reach Production

Roughly 95% of enterprise AI pilots never reach production. That number gets thrown around at conferences like a warning, but it's rarely examined. So let's examine it.

The failure is almost never the model.

The model works fine in the notebook. It works fine in the sandbox. It works fine in the demo. What breaks is everything around the model — the last mile inside a messy enterprise. Data readiness. Eval coverage. Legacy system integration. Change management. Inference cost at scale. Regulatory explainability. The organization's tolerance for technical debt. The cultural willingness to expose bad data rather than hide it.

That is why the frontier labs — OpenAI, Anthropic, Palantir, Google, Databricks — have all quietly started shipping engineers along with their models. Forward Deployed Engineers, Applied AI Engineers, Deployment Engineers — different names, same job. Comp packages at the top of the market. The labs figured out that the bottleneck isn't in the lab. It's in your enterprise.

But hiring a Forward Deployed Engineer from a frontier lab doesn't fix the underlying issue. That engineer is a specialist in making a specific model survive contact with your reality. They are not going to redesign your data governance. They are not going to renegotiate your relationship with the vendor whose data you can't actually trust. They are not going to fix the semantic drift between the way finance defines a customer and the way marketing does.

The real last mile is the data foundation. AI doesn't fail because the model is wrong. It fails because it was built on data nobody vouched for, in systems nobody documented, governed by definitions nobody agreed on.

That is the work. It's less glamorous than the model. It's slower than a proof-of-concept. And it is what separates the 5% of pilots that reach production from the 95% that die there.

Why We Built AI NOW: The Case for a Firm, Not a Freelancer

Enterprise AI isn't a one-person job. Here's what my co-founder Cheryl Dopp and I set out to build — and why we did it together.

When Cheryl Dopp and I started AI NOW, we made a deliberate choice: this would be a firm, not a solo practice.

That distinction matters more than it sounds. The market is flooded with individual AI consultants — many of them talented, some of them excellent. But enterprise AI is not a one-person problem. It sits at the intersection of data architecture, governance, cloud infrastructure, business strategy, regulatory context, and organizational change management. No single practitioner covers all of that credibly. And when the engagement stakes involve Fortune 500 data and regulated industries, the gap between "consultant" and "firm" becomes existential.

The problem we kept seeing

Cheryl has spent nearly three decades inside the data layers of banks, insurers, healthcare systems, federal agencies, and media companies. What she kept observing — and what became the founding thesis of AI NOW — is that enterprise AI initiatives almost never fail at the model. They fail at the data foundation beneath the model. Roughly 95% of enterprise AI pilots never reach production, and the reasons are almost always the same: fragmented definitions, weak governance, master data chaos, architectural debt, and organizational misalignment about what "AI-ready" actually means.

Meanwhile, the market response has been to hire more data scientists and buy more AI platforms. Both help. Neither addresses the underlying problem.

Why a firm, not a freelancer

We built AI NOW as a small, deliberate firm because the work requires two things simultaneously:

Depth of enterprise data experience — the kind that only comes from having built and stabilized data platforms inside dozens of Fortune 500 environments. That's Cheryl's core.

Modern platform, delivery, and operating-model expertise — cloud-native architectures, semantic layers, vector infrastructure, and the operational discipline to actually ship. That's where I come in.

Together, we can walk into an AI readiness engagement and cover the full stack: strategy, architecture, governance, platform selection, and delivery — without handing the client off between three vendors, four consultants, and a systems integrator.

What we're building

AI NOW is intentionally small and senior. We're not scaling into a body-shop consultancy. We're building a firm that can be trusted with the most sensitive parts of an enterprise's data foundation — the parts that determine whether an AI initiative becomes a production system or a very expensive slide deck.

If you're a Chief Data Officer, VP of Data, or Head of AI at a mid-to-large enterprise wrestling with the gap between AI ambition and data reality — that's exactly the conversation we're built for.

More thinking to come.

— Nikita Khlopchatnikov
Co-Founder, AI NOW