Closing the Instruction Gap: Why Prompt Design Is Now a Critical Infrastructure Problem

Enterprise AI has quietly reached a strange point. Companies have poured money into model selection, orchestration, and monitoring, and agentic systems are showing up in banking, healthcare, transportation, and other pieces of critical infrastructure faster than almost anyone predicted two years ago. But the thing that actually determines what an agent tries to do, the prompt behind it, is still mostly treated like a personal skill and an art rather than something an organization can teach or check. 

That gap sits at the center of Dhivya Nagasubramanian’s work. Instead of building another monitoring layer, she put together a structured way to design prompts, one that turns it from something engineers pick up through habit into something a team can actually review together. 

Why Prompt Design Is Now a Critical Infrastructure Problem 

Prompt engineering used to matter less than it does now, mostly because a human was still in the loop. If a chatbot gave a vague or slightly wrong answer, a person read it, noticed, and moved on. That built in check disappears with agentic systems. 

An agent does not just generate text. It reasons through steps, calls tools, writes to databases, and takes actions inside systems that are already running, frequently without anyone reviewing each individual step. So a vague instruction at the start of that chain does not just produce one weak answer. It sets a direction, and everything downstream, every tool call, every follow-on decision, inherits whatever was left unclear at the beginning. A loose constraint that would have been a minor annoyance in a chatbot can become, inside an agent, a route to an outcome that is technically valid and completely wrong, and there is often no one positioned to catch it before it happens. 

This is not hypothetical anymore. Agents are being placed inside banking systems that move money, inside healthcare workflows that manage patient records, inside utility operations. In each case, the instructions given to the agent are really the closest thing the organization has to a record of what it authorized the system to do. 

There is already a case that shows what this looks like when it goes wrong. In Moffatt v. Air Canada, a Canadian tribunal held the airline liable after its customer service chatbot gave a passenger incorrect information about bereavement fares. Air Canada tried arguing the chatbot was a separate entity, responsible for its own words. The tribunal did not buy it, found Air Canada liable for the misinformation, and awarded damages, holding that a company is on the hook for what its AI tells customers regardless of whether the words came from a static page or an automated system. That case involved a single chatbot response, not a multi-step autonomous agent, and it still produced a legal finding against the company. It is a small preview of what happens once the AI in question is not just answering a question but acting on it. 

An Industry with Plenty of Tips and No Real Structure 

There is no shortage of advice on prompt engineering. What is missing is anything that ties it together. Major cloud providers still describe the whole discipline as an art practiced through trial and refinement, which is an honest description, but also kind of the problem in miniature. A field that has to describe itself as an art form does not have a shared standard yet. 

Most practitioner guides read like a long list of individual fixes: be more specific, use examples, adopt a persona, break the task into steps, iterate. Each of these genuinely helps with a narrow failure mode. None of them add up to a framework. It is closer to a collection of home remedies than a discipline, which means how good a given prompt turns out depends a lot on which techniques the person writing it happened to remember that day. One commonly cited breakdown lists ambiguity, inconsistent tone, too much context, and hallucination, the tendency of a model to state things that are not true, as separate problems with separate fixes. Nothing connects them, and nothing tells you which one to worry about first. 

For an individual playing around with a chatbot, that is a minor annoyance. Inside a company, it turns into something closer to a governance problem. There is no shared vocabulary, so when one engineer’s habits differ from another’s, a reviewer has nothing consistent to check the work against. There is no institutional memory either. A good instinct one engineer builds up over years usually just lives in that person’s head and leaves when they do. And there is no way to show your work after the fact. If an agent takes an action that later needs explaining to a regulator or in court, a company that has been prompting ad hoc has nothing principled to point to except the output itself. 

How the 4C Framework Closes the Gap 

Nagasubramanian lays out her answer in Agentic AI for Engineers: Architecting Goal-Driven Systems (Apress, Springer Nature, 2026). She calls it the 4C Framework: Clarity, Context, Constraints, and Care. 

Clarity means stating the task and the outcome in terms that do not leave the model guessing at intent. Context means giving the agent the situational information it actually needs, without burying it under detail that pulls focus away from what matters. Constraints spell out the boundaries the agent has to work within: format, scope, which tools it is allowed to touch, and what outcomes are simply off the table. That last one matters most for agentic risk specifically, since it is what stops an autonomous system from finding a technically legal but genuinely bad way to reach a goal. 

Then there is Care, which most existing guidance skips over completely. It builds a checkpoint for accuracy and bias directly into the prompt itself, instead of leaving that scrutiny for after the agent has already acted. It is the piece most directly tied to that auditability problem: a prompt built with a Care checkpoint gives a company something concrete to show when it needs to demonstrate the instructions were designed with foreseeable risks already in mind. 

“Prompting has always been treated like something you get better at through trial and error,” Nagasubramanian said. “That is fine when a bad output just means someone rereads a paragraph. It stops being fine once the output is an agent doing something inside a system people actually rely on.” 

The result is not a longer checklist. It is a smaller, more disciplined one, four dimensions instead of a dozen scattered techniques, structured so a reviewer can walk through a prompt the way a code reviewer walks through a pull request, checking each dimension in turn rather than relying on intuition about whether something feels right. 

Where It Has Landed, and Why the Timing Matters 

The framework has not stayed confined to the book. Since publication, Agentic AI for Engineers has been accessed through more than seven thousand institutional subscriptions and sits in library systems worldwide, which puts the 4C Framework in front of university and corporate training environments well past whoever bought an individual copy. 

The timing is not a coincidence. Agentic systems are landing inside banking infrastructure, healthcare triage, and energy grid operations right now, in exactly the kind of environment where a poorly specified action can cascade fast and publicly, and where it is the company that deployed the system, not the model provider, left explaining what happened. Prompt design in that setting stops being something that just makes an individual engineer faster. It becomes a governance question, one that belongs next to model evaluation and safety guardrails in how a company thinks about its own risk, rather than sitting underneath them as an afterthought. 

The industry has put real effort into standardizing how agents get evaluated and monitored once they are already running. It has put comparatively little into standardizing the one input that decides what the agent tries to do before any of that monitoring kicks in. Closing that gap does more than improve individual prompts. It gives companies a way to train new engineers on something consistent instead of tribal knowledge, gives reviewers an actual standard to check work against, and, as agentic AI keeps spreading into regulated industries, gives a company something defensible to produce when a regulator eventually asks how a given instruction was designed. 

Conclusion 

The 4C Framework is not pitched as a fix for every failure mode in agentic AI, and it is not meant to replace the monitoring and safety work already underway across the industry. What it offers is something the field has genuinely been missing: a shared way of thinking through the step that comes before everything else an agent does. As agents take on more consequential, less supervised work across the infrastructure people actually depend on, that structure may end up mattering just as much as the systems built to catch what an agent does after it has already been told what to do.