1. What Agentic promises, and the premise it assumes

The Agentic paradigm promises two things. First, it handles dynamic requirements: it does not depend on pre-written processes and can face situations that were never predefined. Second, it exercises autonomy: within a given scope it judges, decides, calls tools, and completes tasks on its own.

Both promises rest on a premise that is usually overlooked: the designer must know where the range of "dynamic" ends and where the boundary of "autonomy" is drawn. In other words, three questions must be answerable: which situations may the Agent decide by itself? which situations must it stop and hand back to a person? and what is the criterion for deciding "do it myself" versus "hand it over"?

If the boundary is not clear, the Agent faces an open situation it cannot truly understand. The problem at that point is often not "one step more or one step less", but a more direct failure: it keeps returning wrong results and never produces usable output; in severe cases it hallucinates, invents facts and processes, and its output detaches completely from reality. Once it reaches this stage, the team no longer dares to let it act autonomously, nor can frequent human review pull it back on track — because the cost of that review approaches the cost of redoing the work, and the Agent loses its reason for existing.

2. Why this boundary cannot be defined

The real difficulty is this: even the designers themselves cannot say where the boundary of a dynamic requirement lies.

Requirements in an enterprise setting do not exist in complete form when a project starts; they surface gradually during implementation. You think you are solving problem A, and as you work you discover that the real constraint is B, and that B in turn depends on the organizational process C — these only reveal themselves once you actually land the system.

In other words, the boundary is not "designed"; it is brought into being by "implementation". Yet the way Agentic runs requires you to hand the boundary over first, and only then can it run autonomously. That produces a contradiction of ordering:

• You need to know the boundary before you can let the Agent be autonomous;
• but you can only know the boundary while the system is running;
• and while the boundary is unclear, the Agent cannot run autonomously with any reliability.

3. AI itself cannot bridge this gap

If AI could work the boundary out for itself during operation, the contradiction would dissolve. At present it cannot, for two reasons.

1. No sense of proportion: no perception of reality, and no experience of bearing consequences

In enterprise settings a great many judgments are about degree: whether this should be done now, how much is enough, how big the risk is, whether to escalate. Such judgments are hard not because of how much information is available, but because of the "degree".

It should be said that a sense of proportion is not something you automatically possess just because you are "in the real world". Plenty of programmers stand in the middle of the situation every day and still get the degree wrong: they fail to escalate what should be escalated, over-engineer what should be closed out, keep pushing what should be stopped. Perception of reality on its own is clearly not enough. A senior engineer and a novice see the same reality; the difference is that the former has borne the consequences of their own judgments — been right, been wrong, been given feedback — and over time has accumulated a tacit judgment that cannot be written down in full.

AI is missing two layers here. First, it has no channel for perceiving reality: all it ever touches is content that has been transcribed into text, and the customer's tone, the atmosphere on site, the team's real load, the unspoken priorities cannot be transcribed into text completely and in time. Second, and more deeply, it has no experiential loop of "make a judgment — bear the consequences — recalibrate on that basis": it never genuinely suffers from a misjudgment, so it has neither the motivation nor the material from which to build a sense of proportion of its own.

So the question is not "whether enough context is provided"; a sense of proportion cannot be acquired by piling up text at all. Even when a person relays reality to it as a medium, that person must also supply the judgment already calibrated by experience — and a person who can do that is themselves the scarcest role on the team. AI can generate an answer, but it cannot judge on its own whether that answer is appropriate or over the line in a real situation.

2. No real capacity for self-directed learning and evolution

During implementation, people reconstruct their own understanding of the problem in response to feedback: it turns out the requirement was not what I assumed, so next time I will do it differently. This is a correction to the frame of the problem itself. Today's Agents, even equipped with memory and feedback loops, mainly accumulate experience inside an established frame; they struggle to discover on their own that "my understanding of the problem is itself wrong" and to restructure the boundary accordingly. They do not grow new responsibility boundaries of their own during implementation.

4. People are also learning as they go, so the boundary keeps moving

For people, implementation is a learning process too. People also work it out as they go: what the real pain point of this scenario is; which steps can genuinely be handed to AI and which will certainly go wrong if handed over; how much autonomy the organization can accept.

So the human–machine boundary is not a static line drawn once and for all, but a line that keeps moving during implementation. People are learning and adjusting their expectations, and AI cannot keep up with that movement — it neither perceives that the boundary has shifted, nor realigns itself.

5. The fatal link: once the requirement is clear, the Agent is no longer needed

The predicament above is already difficult enough, but there is a deeper irony that turns the whole problem from "hard to execute" into "self-contradiction at the level of the paradigm".

When designers finally work out the dynamic requirement, draw the human–machine boundary, and land the process, they discover that the requirement is already stable and structured enough to be implemented with ordinary programs and workflows.

A mismatch in timing follows:

• When the requirement is unclear is exactly when Agent autonomy is most needed to handle the dynamism — but there is no boundary then, so the Agent cannot run autonomously with any reliability;
• by the time people's implementation and learning have made the requirement clear, the Agent finally has a boundary inside which it can run safely — but by then the work within that boundary is a deterministic process, and hard-coded programs and workflows do it more stably, more cheaply, and more controllably than an Agent.

6. The complete chain of failure

Putting all the stages together, the failure is structural, not a matter of execution falling short:

Agentic needs a clear human–machine boundary in order to be autonomous
        ↓
The boundary cannot be settled at design time; it can only emerge during implementation
        ↓
During implementation the boundary moves as people learn
        ↓
AI has no channel to perceive reality, no consequence-calibrated sense of proportion, and does not restructure the problem frame
        ↓
By the time people and the implementation process finally settle the boundary
        ↓
The requirement is already structured enough → deterministic programs / workflows can deliver it
        ↓
Agentic autonomy no longer has any reason to exist in this scenario
        ↓
The stage that truly needs autonomy (the uncertain one) it cannot handle;
the stage it can safely perform (the certain one) does not need it
        ↓
The project fails, or degenerates into "a workflow wearing an Agent shell"

7. This explains a common phenomenon

Many enterprise projects that call themselves Agentic end up, in practice, as:

• using a large model for information extraction or classification at a few fixed nodes;
• wiring those nodes together with a deterministic workflow engine;
• backing every critical branch with rules and human review;
• the so-called "autonomous planning" either switched off, or demonstrated only where it does not matter.

This is not a shortfall in the team's ability; it is the inevitable result of the boundary paradox — once a requirement genuinely runs through and lands, its structure stabilizes to the point where autonomy is no longer needed.

8. The positioning lesson this yields

If the boundary is not designed but emerges during implementation, then the real crux of an enterprise Agent project is not model selection, framework, or model capability, but who keeps defining the human–machine boundary throughout implementation.

This defining work runs through the whole project; it is not a one-off exercise of upfront design or an end-of-project handover. During implementation it must keep answering two kinds of questions:

• Which steps must have people give feedback and make choices — the handling of degree, the bearing of consequences, the reading of a real situation;
• which work can be handed to AI to carry out — the parts where the boundary is relatively clear, the cost of a mistake is controllable, and the result can be verified.

And this line moves as people's understanding of the requirement deepens: a step that needs a person today may be handed to AI tomorrow once its pattern has been worked out; a step handed to AI today may be taken back because it runs into a new real-world situation. Defining the boundary is itself the core content of implementation, not a formality completed before implementation begins.

There is a premise here that is often overlooked: this work must be done by someone with the ability to abstract logically and to learn quickly and autonomously during implementation. They must be able to distill stable judgment rules out of scattered trial and feedback, telling which cases are incidental and which will recur; they must be able to locate the "degree", knowing at which step handing anything further over would mean losing control. Without such a role, the boundary either never settles or gets fixed in the wrong place, and the project fails naturally. Adding more engineers or a larger model cannot substitute for it.

So the realistic positioning for enterprise Agents should be:

• Do not set out to deploy an autonomous Agent to run the business from day one. While the boundary is unsettled, full autonomy is bound to overstep it; a process that can be fully hard-coded is not worth using an Agent for.
• Make "defining the human–machine boundary during implementation" the main line of the project, led by someone with abstraction and learning ability, with the Agent as their tool for exploring, trialing, and generalizing inside that boundary.
• Adjust the boundary as understanding iterates: whatever stabilizes is precipitated into a workflow; whatever newly surfaces goes back into human–Agent collaboration. The workflow is not a one-off deliverable produced at the end of the project, but a continuous deposit accumulated while the boundary is being defined.

9. In passing: which tasks are actually suited to free Agent exploration

This does not mean Agent autonomy is useless; it means it has to be used in the right place. Tasks suited to free exploration mostly fall inside the intersection of the two conditions from section 7 — the answer cannot be structured in advance, and the cost of trial and error is tolerable. Specifically, there are several kinds:

• Material synthesis and option comparison. Gathering existing material around a relatively clear topic, comparing several ready-made options, and organizing them into structured conclusions. The information space is known, and the emphasis is on synthesis; if something is missed or the direction drifts, a person can correct it at a glance.
• Creative and content generation. Copy, naming, stories, divergent design. The output is inherently "give a few versions for a person to choose from"; being wrong does no real harm, and the more divergent it is, the more valuable it becomes.
• Exploratory research. Spreading the search across domains where the result itself is unknown — investigating unfamiliar technical directions, triaging large volumes of leads, testing multiple hypotheses in parallel. Done by hand this work is slow and heavy; a person's real bottleneck is the speed of traversal and filtering. An Agent can, in a short time, range widely across a field, run the trials, and consolidate the results, freeing people from the heavy traversal while they judge which leads are worth pursuing.
• Dynamic validation and process probing. The Agent keeps generating test inputs on its own to run through and stress a process, adjusting the next round of probes according to the returned results. Take a RAG question-answering system as an example: the AI can continuously generate questions from different angles, at different difficulties, even deliberately tricky ones, to check whether retrieval hits, whether answers are accurate, and where hallucination appears, then press further on the weak spots it exposes. Such validation is monotonous and hard to cover comprehensively by hand, whereas an Agent can continuously, at volume, and across many dimensions actively probe out a process's boundary and defects.

What these tasks have in common is: the person is always the acceptor of the result, rather than ceding decision-making power to the Agent; the Agent is responsible for divergence and probing, the person for convergence and the final call. Conversely, once a task requires every decision to be correct, errors carry real business consequences, and the answer should be fixed and structured — then it should run as a workflow, rather than being entrusted to an Agent's free exploration.