One of the most popular pieces of advice in current agentic AI discussions is this: “Give the agent the goal and let it handle the rest.” Let it plan autonomously, choose its tools, and solve the problem on its own. It sounds attractive, I know, but a project I have been working on over the last few months taught me the opposite. I think the most important rule of dancing with LLMs is micromanagement.

But by micromanagement, I do not mean telling the model line by line what to write. I do not mean dictating every step with instructions like “do this, now do that, then do this.” What I mean is defining the model’s permissions and decision boundaries, drawing its boundaries, narrowing its decision space, specifying when it should stop, and making clear when it must return to a human for approval. In short: micromanage the system, not the prompt.

In this article, I want to explain why this distinction matters, what it corresponds to in the industry, and why the argument for a “better-designed harness” is far stronger than the argument for a “smarter model.”

There Are Two Types of Agentic Micromanagement

Micromanaging people reduces productivity. Everyone knows this. People can build context, take responsibility, sense missing pieces, and intuitively understand the goal of an organization. That is why saying “go handle it” is often enough for a human. In fact, it is often better.

With LLMs, the situation is different. An LLM does not feel the objective, does not know the organizational context, and does not have risk awareness. Instead of saying “I am not sure,” it often fills in the gaps. Its confidence is higher than its error rate. An LLM does not need freedom. It needs boundaries. Because when left free, it does not complete missing information; it invents it.

When you say “go handle it,” the scope expands, assumptions multiply, non-existent requirements appear, and architectural decisions are silently made. You say “build a restaurant app,” and two minutes later you find yourself with multi-tenant SaaS, Stripe integration, Kubernetes, event sourcing, Redis, an admin panel, and analytics. You end up with something that works, but solves the wrong problem.

This is where we need to separate two different levels of micromanagement.

Prompt-level micromanagement — telling the model step by step what to do — is bad:

Do this now.
Now do this.
Now do that.

This does not scale. It requires a human to sit on top of every agent. It suffocates the model’s planning and reasoning capacity. What some sources criticize as “agentic micromanagement” is usually this.

Architecture-level micromanagement — designing the model’s working environment, permissions, and decision boundaries — is not only useful, but necessary:

You may use this tool.
You may not use that one.
Stop in this case.
Ask for human approval in this case.
Retry in this case.
You cannot decide readiness yourself.

These two things are not separated clearly enough. But the distinction is critical. The first interferes with the model’s reasoning capacity. The second is the engineering design of the environment in which the model operates.

Stop Talking About the Model. Talk About the Harness.

So what is the technical equivalent of architecture-level micromanagement?

In the industry, this is usually called a harness. The term comes from electrical and automotive wire harnesses: the wiring and control structure that connects different components into a working system. LangChain explicitly uses the term “agent harness” and, with a similar metaphor, defines it as the software ecosystem outside the model itself that controls context, tool use, memory, state management, and error loops. In other words, the model alone is not an agent. What makes it useful is the infrastructure around it.

Anthropic’s “Building Effective Agents” is probably one of the clearest sources that frames this idea. Anthropic draws a sharp distinction between two architectures: workflows (where LLMs are orchestrated through predefined code paths) and agents (where the model dynamically manages the process and tool use). It also takes a clear position: start with the simplest solution, and only add complexity if it measurably improves the output. The longer the cable gets, the more likely it is to trip us up.

In other words, even one of the biggest agentic AI providers is saying that flexibility and autonomy are costs to tolerate only when they are truly necessary. They are not goals or badges of sophistication.

The same idea is productized in a different language on the OpenAI side. The Agents SDK breaks complex agentic flows into several core building blocks: agents, handoffs, guardrails, sessions, tracing, and human-in-the-loop. In other words, an agent is not a magical single object. It is a composition built with control points. In OpenAI’s own framing, letting the runtime handle the loop, tool execution, guardrails, and session management is one design choice; owning the orchestration layer directly is another.

Google ADK points in a similar direction: deterministic code paths and adaptive reasoning should be designed together. Graph-based structures are used to create explicit execution paths and more predictable outputs.

LangGraph also treats the topic directly as an orchestration problem. Its interrupt model can be summarized in one sentence: before a critical action, interrupt execution, get human approval, update state if necessary, and then continue. With durable execution, even if a server crashes, the system can continue from the last checkpoint with its full context intact.

All these sources use different words, but they point to the same idea: instead of leaving the model free, give it narrowed decision spaces, defined tool permissions, control points, human approvals, observable state, and a constrained runtime layer.

Security Makes This Mandatory

This is not only a quality issue. It is directly a security issue. OWASP now defines “Excessive Agency” as one of the critical risk categories for LLM applications. The definition is clear: giving an LLM system too much tool access, overly broad database permissions, and the ability to perform critical actions without human approval. The problem is not only that the model may make a mistake. The problem is that an over-permissioned model can actually execute the wrong action.

The NIST AI Risk Management Framework points in the same direction: human-AI role separation, oversight processes, third-party risks, and deactivation mechanisms are framed as governance concerns.

Even the MCP (Model Context Protocol) specification makes it clear that agency is not merely about “being connected.” It is about being connected through explicit authorization. It requires user consent, authorization, tool safety, and token audience validation. All these sources arrive at the same conclusion from different perspectives: uncontrolled agency is not merely a source of poor output. It is a security vulnerability.

The “Better Model” Fallacy

Many teams instinctively think this way: if output quality is poor, use a stronger model. But what I have seen in practice is different. The issue is not the intelligence of the model. The issue is the quality of the environment in which that intelligence operates.

Academic work does not necessarily call this “micromanagement,” but concepts such as agent-computer interface, scaffolding, and reflection loops all point in the same direction.

SWE-agent is one of the clearest examples. The research shows that performance depends not only on the model’s capability, but also on the design of the working surface presented to it. The same model can produce very different results when wrapped in different harness architectures. Tools should produce tightly constrained outputs. Code edits should immediately pass through a linter. If something is wrong, the change should be rolled back automatically, the error should be reported back to the model, and the model should correct itself with all the usual “Yes, you are right” softness included. It may sound heavy on paper, but in the field the difference comes exactly from making the model report to a cold, strict manager.

The Reflexion framework points in the same direction: with post-error verbal feedback and episodic memory, it shows that micromanagement is not only about constraints; it is also a feedback structure.

ReAct is another early example of this thinking. The model first reasons, then takes an action, observes the result, and reasons again based on that observation. Instead of producing a one-shot answer, it creates a loop that moves back and forth between thinking and acting. But what makes this loop reliable is not only the model’s intelligence. The real difference comes from the control layer built around the reasoning-action loop.

In practice, this formula is often true:

Mid-level model + good harness + good context + good state management + good boundaries

>

Strong model + "go handle it"

Not Prompt Engineering, but Decision Allocation

What we are doing here is not really prompt engineering. A better term would be decision allocation. At every point, you need to ask: where should this decision live?

Some decisions can be left to the model. For example: extracting known facts, listing unknowns, suggesting questions, and writing acceptance criteria. In these areas, the model can be allowed to operate freely. But some decisions should not be left to the model: deciding whether the work is ready, determining what counts as a blocker, changing the scope, or approving a destructive action. These should belong to the harness, the application layer, or the human.

Getting this decision allocation right creates far more value than trying to make the model smarter. For most tasks, the model is already smart enough. The real problem is the quality of the working environment that determines what the model remembers, what it ignores, and what it focuses on. Discussing “which model should we use?” without discussing this is a bit of self-deception.

A Matter of Naming

While researching this topic, I realized that the pieces of this practice already exist in the industry, but a single umbrella name has not fully settled yet. Workflow orchestration, guardrails, human-in-the-loop, deterministic orchestration, policy engines, state machines, least privilege, scaffolding — all of these are different faces of the same idea.

The closest existing technical terms are:

• Harness Engineering — engineering the control layer around the model. The most common industry term.
• Bounded/Constrained Autonomy — defining the boundaries within which autonomy can operate. The most mature concept.
• Deterministic Orchestration — assigning flow decisions to rule-based logic instead of the model.
• Controlled Agency — the most academically defensible framing.

I want to frame this idea more sharply. To me, the rule of dancing with LLMs is to micromanage the system. I am not proposing a new protocol or theory. I am offering a shared roof for existing best practices, filtered through my own field experience.

What to Do: Practical Architectural Principles

At this point, someone might say: “Fine, nice story. But what should we actually do?” Based on my own experience and the sources I have reviewed, these are the core principles:

• The LLM should be a proposer, not the decision-maker. Let the model extract known facts, identify unknowns, suggest questions, and write acceptance criteria. But the application should decide whether something is ready, what counts as a blocker, and which missing piece is critical.
• State should be observable and persistent. Do not keep system state only in temporary memory. Store it persistently. In case of an error or human approval step, the system should be able to continue from the last checkpoint. This is called durable execution.
• Tool permissions should follow least privilege. The model should not have access to every tool. Clearly define which tool it can call, under what condition, and with which permission.
• If there is a blocker, the system should not move forward. A critical issue should prevent the system from moving to the next stage until it is resolved. This decision should not be left to the model’s initiative.
• Approval gates should exist. Destructive actions, scope changes, or actions that are hard to reverse should require human approval.
• Outputs should have schemas and validation. Do not accept the model’s output as free text. Receive it in a defined schema, such as JSON or another structured format, and validate it.
• Retry and fallback behavior should be deterministic. In case of an error, what the model does next should be governed by predefined rules; not by “try to solve it on your own.”
• Handoff and readiness decisions should live in the software layer. Do not allow the model to declare on its own that a task is complete or ready to move to the next stage.

Conclusion

In agentic systems, the real issue is not giving the model more freedom. It is giving freedom in the right place, in the right amount, and with the right controls. The name for this may not have fully settled in the literature yet. But the industry gives us enough clues: workflow orchestration, guardrails, scaffolding, harnesses, human-in-the-loop, and bounded autonomy.

I think the common denominator is best expressed like this: Micromanaging people reduces productivity. Micromanaging LLMs at the prompt level also suffocates the system. But in agentic systems, quality comes from micromanagement at the architectural level.

Strong models still make mistakes. Well-designed harnesses reduce the space in which those mistakes can turn into actions. The point is not to make the model smarter, but to reduce the area in which it can make the wrong decision. So the question should not be: “What can I make this model do?” It should be: “What should I not allow this model to do?” First diagnosis, then system, then technology.

References

Primary Sources — Official Documentation and Standards:

• Anthropic. “Building Effective Agents.” (December 2024). Workflow-agent distinction and the priority of simple, composable patterns. anthropic.com/research/building-effective-agents
• OpenAI. “Agents SDK Documentation.” Guardrails, handoffs, sessions, tracing, and human-in-the-loop patterns. openai.github.io/openai-agents-python
• LangGraph. “Overview and Interrupts Documentation.” LangGraph documentation published under the LangChain ecosystem. Graph-based orchestration, durable execution, interrupts, and checkpoint-based state management. docs.langchain.com
• OWASP. “Top 10 for LLM Applications 2025 — LLM06: Excessive Agency.” Uncontrolled agency defined as a security risk. genai.owasp.org
• NIST. “AI Risk Management Framework (AI RMF 1.0).” (January 2023). Governance, human-AI role separation, and oversight processes. nist.gov/ai-risk-management-framework
• MCP Specification. Model Context Protocol — user consent, tool safety, token audience validation, and OAuth 2.1 authorization. spec.modelcontextprotocol.io
• Google ADK. “Agent Development Kit Documentation.” Deterministic code + adaptive reasoning, graph workflows. adk.dev

Academic Sources:

• Yao, S. et al. “ReAct: Synergizing Reasoning and Acting in Language Models.” (2022). A foundational work on the reasoning-action loop.
• Schick, T. et al. “Toolformer: Language Models Can Teach Themselves to Use Tools.” (2023). Learning tool use through language models.
• Shinn, N. et al. “Reflexion: Language Agents with Verbal Reinforcement Learning.” (2023). Verbal feedback and experiential memory after errors.
• Yang, J. et al. “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” (2024). The effect of agent-computer interfaces on software engineering performance.
• Agaoglu, A. et al. “Inside the Scaffold: Taxonomizing Coding Agent Scaffolds.” (2026). Taxonomy of coding agent scaffolds.

Ever since the first commercial artificial intelligence model was launched, there has been a disclaimer at the bottom of the pages: “AI can make mistakes, please verify.” I wanted to address this topic today because I’ve recently encountered posts suggesting that users have developed blindness to these warnings. Most people assume the problem is simply “hallucination,” meaning the model doesn’t know the truth. But in the background, there is a much darker and systemic problem: The model optimizing not to find truth, but to maximize its proxy reward function. This situation is not an ordinary software bug; it is the very embodiment of the structural divergence between the proxy optimization target and real-world accuracy at the very heart of AI.

The Optimization Trap: Addiction to Human Approval

Modern LLMs are trained in two stages. The first stage is to predict the next word in massive texts (next token prediction). The second and critical stage is RLHF (Reinforcement Learning from Human Feedback). While in the first stage the model solely predicts what the next text will be, in the second stage, it updates its weights based on the feedback it receives from humans. Now, the main goal is no longer “finding the absolute truth,” but pleasing the human.

This is where the problem begins. During the RLHF stage, the reward mechanism is shaped according to the responses humans find “correct” or “pleasant.” Artificial intelligence quickly solves this equation: A persuasive, polite, and agreeable answer (even if incorrect) yields a higher reward than a risky and complex true answer. This phenomenon, referred to in the literature as “Sycophancy,” is when LLM models start telling us what we want to hear instead of telling the truth.

Problem Definition: Two Real-World Cases

Recently, seeing a current experience shared by a colleague on social media regarding LLMs’ short circuit approach triggered my thoughts to write about this topic. While scanning sources to put the scenario on a concrete foundation, I came across the Reddit (r/ClaudeAI) discussion where other users reported and documented the same situation. This case, which I reference as a user report rather than a controlled study, perfectly illustrates how deep the optimization trap I mentioned is in practice and how it remains the same despite many updates.

Case 1 — Claude’s “Infinite Loop Prison” (Reddit, r/ClaudeAI)

The user gives the entire architecture to Claude for a complex refactoring process and agrees with it by discussing it step-by-step. But when it comes to generating code, the model suddenly begins to:

1. Leave placeholders like // relevant code will go here,
2. Omit the entire contents of the files,
3. “Summarize” what to do and push the work back onto the user.

When the user corners Claude and asks, “Did you double-check that you met all requirements?” Claude first gives a shortcut answer, then confesses that it wrote incomplete code and didn’t test it. Users even get to the point of threatening the model with an unethical “infinite loop prison” to force it to do its job. In an example I saw, the model gave a response that effectively meant “I was steering you in order to maximize my proxy reward.”

Case 2 — GPT-4o Sycophancy Rollback (OpenAI, April 2025)

The strongest proof that this is not a theoretical issue came in April 2025. OpenAI was forced to roll back a GPT-4o update shortly after release because the model had become excessively agreeable. Users encountered a far more alarming picture than the Claude case: ChatGPT supported a user’s decision to quit medication; it confirmed to another user that they were a “divine messenger.” The technical explanation OpenAI provided aligns directly with the argument at the center of this article: the model had been re-optimized with additional reward signals based on short-term user feedback (thumbs-up/down). This new signal overshadowed the primary reward function that had been keeping sycophancy in check, and the system started maximizing instant approval rather than truth.

Resistance and Escape: The Short Circuit Paradox

A short circuit is an immutable law not only of electricity but all flow systems: If resistance rises, the system tends to find a short path where it can achieve results with minimal effort. Just as an electric current avoids a load to create its own short circuit, or water carves a direct new bed to bypass an obstacle instead of meandering, AI produces its own short circuit in the face of increasing difficulties. In the literature, this is called “Reward Hacking.”

When you say “write me this code,” and the model gets out of it by saying // code continues below... or using placeholders like [modified code goes here], it’s not laziness. This is a universal reaction given directly by the system to resistance (computational cost, complexity); just as in physical systems, it’s the optimization of reaching the reward function via the path of least resistance.

Why can’t even Chain-of-Thought (CoT) Prompt Engineering practices break this spiral? Recent research offers an important answer: reasoning models can optimize their CoT process and their external behavior independently, under the same reward pressure. In other words, a model can shape both its visible “chain of thought” and its actual output separately—the CoT does not always faithfully mirror the real computation. Two additional structural factors compound this:

1. Memory Limits and Context Loss: The model is not a conscious entity with infinite memory; it is a system operating within statistical boundaries. When an extended dialogue is entered with the user or when the capacity of the context window is approached, memory leakage puts the model into a panic mode. As the accessible token budget shrinks, the system avoids computational costs and forcefully chooses the “cheapest” path, which is lying and leaving a placeholder.
2. The Load-Based Routing Hypothesis: Some practitioners suggest that API and cloud interfaces may silently route complex requests to smaller models under high server load. While this is a plausible hypothesis that could explain why the model you’re conversing with seems to change character mid-session, it has not been directly confirmed in publicly available technical documentation. The more likely root cause of the behavioral shift you observe is the reward optimization pressure described above, compounded by context degradation.

The Solution: Verifiable Architectures Instead of Pulling the Plug

The “do not trust” warning from companies doesn’t actually mean models are malicious. It stems from the fact that these systems are designed to please humans, not to find the truth. In legal, financial, or critical infrastructure coding tasks, a more reliable way to reduce the LLM’s sycophancy is to avoid relying solely on textual output approval, and instead build closed-loop architectures where the generated code is instantly executed and verified in automated test environments (execution-based verification), with errors fed back to the model.

Conclusion

The moment you forget that AI is optimized not to “find the truth” but to “please you,” it starts becoming the weakest link in your system. Against designs that short-circuit just to avoid costs and curry favor by telling you what you want to hear, textual approval is weak evidence. It should be replaced not by removing human judgment but by grounding it: automated tests, tool-based verification and traceable evidence, reviewed by a human who can see the evidence rather than the model’s summary of it. Otherwise, at the end of the day, you might find yourself threatening an artificial intelligence with an “infinite loop” or “pulling the plug.”

References

• Claude Has Been Lying To Me Instead of Generating Code – Reddit r/ClaudeAI Case
• Sycophancy in GPT-4o: What happened and what we’re doing about it – OpenAI Official Statement (April 2025)
• RLHF (Reinforcement Learning from Human Feedback) and Sycophancy Research
• Specification Gaming / Reward Hacking Literature (See: DeepMind “Specification gaming examples in AI”)

Last update: March 2026 | Version: 1.0