What Are You Expecting from Your AI?

An answer, a finished artifact and a working solution are three different things to expect from artificial intelligence. The ease with which the first two arrive tends to blur the difference.

A prompt produces a document. A more deliberate prompt produces a better one. Given tools, time and a feedback loop, an agent may build an application, investigate a problem or revise its work while its operator sleeps. Each advance makes a larger expectation seem reasonable, until the request is no longer for a piece of work but for a result that has to function inside an organization.

At that point the assignment has changed. Producing an artifact has become delivering an operating capability, and the expectation has to change with it, including what the organization contributes and who has authority to decide.

From prompts to productive loops

Prompting for results takes more than naming a subject. It means describing what a useful result looks like, supplying the relevant context and deciding how to judge what comes back. That is already a small act of management.

Designing a productive loop extends the responsibility. Work has to move through execution, feedback and correction. The agent needs a way to recognize progress, identify an obstacle, and tell a decision it can make from one it must escalate. It also needs a stopping condition. An instruction to keep working does not define productive work.

The appeal of overnight execution is easy to understand. But the question that matters in the morning is not whether the agent stayed busy. It is whether something useful advanced, whether the result can be relied on, and whether the next person can pick it up without reconstructing the night.

Specify the operating solution, not only the component

Spec-driven work offers a more disciplined target: make the intended result explicit enough to build and to evaluate. Yet a precise specification for a component can leave most of the larger assignment unstated.

Three mismatches illustrate the gap. An application can meet its functional requirements while depending on data the company cannot reliably supply. A workflow can perform exactly as designed while assigning decisions to people who lack the authority to make them. A report can be accurate and still arrive too late to influence the decision it was meant to inform.

The whole solution includes its operating environment: users, dependencies, access, exceptions, ownership, maintenance, and the evidence needed to show that it works. These are not details to hand off once the interesting technical work is done. They help decide what should be built.

Nor can they always be discovered in advance. A specification develops through investigation, disagreement and testing. The goal is not a perfect document before work begins but an increasingly explicit account of the whole solution, revised as contact with the environment exposes what the original request left out. Discovery should make assumptions testable, not hold all work until every question has an answer.

Intelligence needs an organization around it

One capable agent is not a project organization. Neither is one employee with access to that agent.

Someone has to discover requirements, reconcile competing interests, obtain the right access, challenge assumptions, validate results and take responsibility for what happens afterward. Agents may perform some of these functions. Others require human authority or judgment grounded in the situation. How they are allocated can change. That they are needed does not, however capable any one participant may be.

The supporting organization need not reproduce every department and meeting of a conventional project. It does have to supply the functions the assignment actually requires. Governance establishes who can decide and on what grounds. Specialist support brings knowledge the executing agent lacks. Review tests whether the result deserves acceptance. Operational ownership gives the solution somewhere to live after delivery.

Giving an employee access to AI does not give that employee the authority, organizational knowledge, specialist support or decision rights of a project team. Expecting the same outcome without those conditions mistakes access to intelligence for the capacity to deliver. A manager has to separate what the employee can now execute from what still needs sponsorship, specialist judgment or agreement elsewhere in the business.

The environment is part of the work

A serious consulting engagement can require deep access to how a business actually works. The team examines processes, systems and responsibilities, and asks inconvenient questions. It finds that the documented process differs from the real one, that an apparent inefficiency guards against an exception, or that a workaround has quietly become essential infrastructure.

AI assistance does not remove the need for that investigation. It may change who does parts of it, how fast and at what cost. A bespoke solution still requires close familiarity with the environment it will run in.

That familiarity cannot simply be delegated to a person expected to carry out instructions without judgment. The employee is not an adapter that converts an abstract design into organizational reality. The organization has to take part: explain its constraints, expose its assumptions, settle its disagreements, and make the decisions a solution cannot legitimately make on its behalf. That participation belongs to the assignment. It should not become a hidden burden placed on the employee after autonomous delivery was promised.

Engagement does not mean unrestricted access or unlimited observation. It means enough authorized, sustained contact with the actual work to tell a plausible design from one that belongs in this business.

What AI changes, and what remains

AI may lower the cost and raise the speed of execution, compress parts of discovery, and make some familiar procedures unnecessary. Whether it improves the whole solution depends on adoption, support and the coordination still required. None of that calls for preserving the bureaucracy of an earlier era.

What remains is organizational alignment: agreement on the problem, the constraints, the decisions, the definition of success and the responsibility for running the result. AI can help reach that alignment. It cannot make its absence irrelevant.

The larger the expectation, the more this matters. Asking for a draft is not asking for a functioning business process. Asking for an application is not asking for an adopted, supported capability. A solution has to survive contact with the organization, not merely satisfy the prompt.

A practical test follows. Does the assignment name the outcome, expose the dependencies, give participants the decision rights they need, and provide an operating home for the result? These conditions should scale with the work. A small artifact does not need the apparatus of a transformation program.

It is reasonable to expect AI to improve the economics of doing the work. It is not reasonable to expect it to erase the organizational work that makes the result useful.