AI automation stays fragile when intent isn't portable

AI makes context portability visible

Insight: AI is not just a productivity tool; it is a diagnostic instrument for hidden context.

For decades, organizations automated the explicit layer and left the implicit layer untouched. They automated transactions, workflows, reports, and integrations. They formalized what was already clear: fields, handoffs, approvals, states.

What stayed implicit was the invisible layer of assumptions, definitions, trade-offs, and decision rules that lived in people’s heads. That worked because automation was expensive. When automation is expensive, only stable work gets automated. Everything ambiguous stays “human”, and insiders quietly reconstruct intent from context.

AI changes the economics. Automation is no longer rare or costly. It is conversational, fast, and widely accessible. You can try to automate thinking itself with a prompt, and the first version can look solid.

The fragility shows up under variation: edge cases, different customers, different reviewers, different weeks. Consistency becomes the hard part. When context is missing, failure is not always immediate or obvious; it’s often plausible but wrong outputs, silent drift, and escalations that cluster later.

That brittleness isn’t random. It usually means the organization depends on context that was never made explicit.

This happens because AI cannot fill the gaps humans fill automatically: undefined terms, unstated constraints, and invisible decision rules.

In one minute

• When AI outputs look plausible but vary across similar cases, they are revealing missing context, not model weakness.
• The constraint moves from “can this be automated?” to “is the intent portable enough to automate reliably?”
• Start with one decision type: define terms, constraints, and escalation triggers, then test them against a small case set.

Where “off” outputs come from

The pattern usually shows up in a familiar moment: a leader asks a team to “automate the workflow” or “use an agent to handle requests”. The prompt sounds reasonable: “triage urgent tickets”, “ship the fix”, “close when done”.

Humans hear those words and silently apply a shared mental model:

Urgent for whom? Affected customers or internal deadlines? What is the risk tolerance? Which clients are regulated? What promises were already made? Who can override the default, and in which forum?

An AI system cannot guess those rules the way insiders do. It executes the literal request. Sometimes the output feels wrong immediately. Sometimes it looks fine, until an edge case hits or two similar cases get two different answers.

The instinct is to blame the model. But the more useful interpretation is simpler: the request relied on implicit context that never traveled.

In practice, someone becomes the translator: they rewrite prompts, add ad hoc constraints, paste prior decisions, and walk exceptions through. Work still gets done, but the truth becomes clear: the automation depends on an insider.

That is the bottleneck shift. The constraint is no longer technology. The constraint is whether the intent behind a decision can move across people, teams, time, and tools without being reinterpreted.

Context portability is a design property

By context portability, I mean the minimum assumptions and decision rules required to reproduce a decision are explicit enough that someone (or something) outside the original room can execute it with the same intent.

This is not a documentation problem. It is a design problem. If critical decisions depend on “people who just know”, the organization is fragile: scale increases misalignment, turnover increases risk, and cross-team work increases negotiation cost. AI removes the economic and human-translation buffer that used to compensate for implicit intent.

The mechanism is straightforward:

• Humans compress meaning to move fast in conversation, and fill gaps with shared history.
• Cheap automation makes those gaps visible because it cannot reconstruct intent from insider context.
• Each “off” output is a portability test: it shows which definitions, constraints, and authority boundaries were never operational.

The decision contract is what makes intent portable. It is not a document dump; it’s the minimum execution spec for a decision so it survives new people, new tools, and new weeks.

This is less acute when decisions are low-stakes, teams are stable, and the work stays within one shared context. It becomes acute when work crosses functions, risk boundaries, and time horizons, or when you try to scale automation beyond the original insiders.

The opportunity isn’t to eliminate tacit knowledge; it’s to decide which parts must become portable for reliable automation. Expertise will always matter, but portability is what keeps intent consistent under variation.

Signals you have a context portability gap

Look for signals in escalation logs, ticket churn, meeting artifacts, onboarding material, and the prompt libraries people build. Portability gaps leave operational fingerprints.

Insider-dependent prompts. The “best prompt” is a person’s private snippet collection, not a shared artifact anyone can reuse. That is context trapped in individuals. A good first move is to turn the top snippets into a shared decision contract with owners and versioning.

Plausible inconsistency. Similar cases get different outcomes depending on who prompted, which examples were pasted, or which day it ran. That is not “randomness”; it is missing decision rules. Start by building a small case set for one workflow and using it as a regression check for the contract.

Recurring arguments about basic words. The same terms keep resurfacing in reviews: “urgent”, “done”, “acceptable risk”, “VIP customer”. When definitions drift, execution fragments. Start by creating a small glossary for one workflow and forcing one forum to use it for two weeks.

Escalations cluster around the same exceptions. Overrides and manual approvals repeatedly happen for the same edge cases (“regulated client”, “high-dollar refund”, “security exception”). That is an invisible policy. Start by logging exceptions with owner and expiry, then decide whether they are true rules or temporary debt.

Onboarding requires apprenticeship. New hires learn by shadowing, because the organization cannot point to a compact artifact that explains how decisions are made. That is low context portability. Start by capturing the minimum decision rules for one recurring decision type and using it as the onboarding reference.

Make intent portable, then automate

Suggested moves, not mandates. Pick one to try for 1–2 weeks, then review what you learned.

Write a decision contract for one workflow

Pick one recurring decision type you want to automate (triage, refunds, access approvals, risk exceptions) and write a one-page decision contract: definitions that cannot drift, constraints that must hold, and boundary examples that make “in” vs “out” unambiguous. This works because the fastest way to improve AI outcomes is to reduce interpretation, not to add more prompts.

Start with the decision that triggers the most rework. Watch for fewer “what do we mean?” loops and fewer escalations driven by basic ambiguity.

Turn escalations into a portability backlog

Treat every “off” output, inconsistent result, and manual override as data. Capture the missing definition or constraint, add it to the decision contract, and version the change. Keep a small test set of real cases so you can rerun it whenever the contract changes and see whether consistency is improving. This works because portability is built from real cases, not from imagined completeness.

Start by reviewing one week of escalations and collecting around 20 past cases with expected outcomes. Watch the repeat rate of the same exception and the variance across similar cases, not just whether the workflow “runs”.

Design authority boundaries and escalation triggers

Make “who can override what” explicit for the workflow, and define escalation triggers that are safe and cheap (thresholds, risk flags, client classes). This works because reliability comes from known boundaries, not from perfect predictions.

Start by choosing one boundary that currently lives as folklore and turning it into a rule with an owner and a review cadence. Watch override volume, decision latency, and whether the team trusts the defaults enough to stop re-litigating them.

---

AI makes a lot of work feel automatable, and early wins can be real. The trap is thinking the limiting factor is the model. In many organizations, the limiting factor is that intent does not travel: meaning is compressed, definitions drift, and decision rules stay local to the people and forums where they were formed.

If you treat AI as a diagnostic, you gain a new modernization lever. Where prompts require insiders to translate intent, you have found a portability gap. The work is to redesign until the minimum context needed for the decision is portable and owned.

Which recurring decision in your organization still needs an insider to translate the intent?