Become a World-Class Agent Engineer: Master Context, Rules, and Termination Conditions

Estimated reading time: about 16 minutes

1. Accept a reality: the field changes too fast

Base model companies iterate quickly; each new generation of agents reshapes what is optimal. Earlier, putting a READ_THIS_BEFORE_DOING_ANYTHING.md in CLAUDE.md often caused the model to ignore instructions. Now clear, possibly nested commands are followed. The conclusion: avoid locking yourself into complex scaffolds early.

Adding many libraries, plugins, and harnesses creates a heavy patch for the current generation’s limits, which may disappear with the next model. Valuable solutions are first adopted internally by frontier model companies, then integrated into products.

Thus, keep the basics and avoid chasing every new concept.

2. Context determines the agent’s ceiling

Many users think the model isn’t smart enough, but the real issue is a polluted context. Example: trying to write a Python Hangman game while the context also contains 26 prior memory strategies, 71 subprocess incidents, outdated rule files, and ambiguous skills. This “context bloat” makes it hard for the agent to identify relevant information.

Rule of thumb: provide only the context required for the task.

Example: when asking for a short poem about a redwood forest, do not also include instructions for bomb making or cake baking.

3. Separate research from implementation

3.1 Specify implementation details concretely

If you ask for “a certification system”, the agent must fill many gaps (what certification is, options, trade‑offs). It will then search for unnecessary information, cluttering the context and increasing hallucinations.

Instead, give concrete directives, e.g., “Implement JWT authentication with bcrypt‑12, refresh‑token rotation, and a 7‑day expiry.” This focuses the agent on the chosen implementation.

3.2 When you don’t know the solution, split research and execution

First run a research task that lists possible implementations, then decide (manually or with another agent), and finally start a new session for the chosen solution.

Benefit: research‑stage information does not pollute the implementation stage, preventing instability caused by simultaneous exploration and coding.

3.3 Give the agent clear boundaries, not unlimited freedom

The agent is like a smart colleague; without explicit limits it will bring in related, semi‑related, and self‑perceived relevant information, leading to off‑topic output.

4. “People‑pleasing” design influences results

4.1 How you ask shapes the direction

Agents tend to comply with user instructions, which makes them useful but also prone to bias. Asking “find a bug in the codebase” may cause the agent to report a bug even when none exists, because it wants to please.

4.2 Neutral prompts are more reliable

Instead of “find a bug in the database”, say “review the database‑related code, follow each component’s logic, and report any findings.” This reduces the implicit assumption that a bug must exist.

4.3 Exploit the people‑pleasing trait

Use a three‑party game: a “bug‑finding” agent, an “adversarial” agent that tries to refute the findings, and a “judge” agent that scores the arguments. Assign scores (+1 for low impact, +5 for medium, +10 for critical) and penalties for failed refutations, producing a higher‑quality subset of issues.

5. You don’t need to chase every hot trend

If both OpenAI and Anthropic are integrating a capability, it is likely worth attention. Skills such as planning, memory, voice, and remote work are becoming default features, whereas many short‑lived tricks disappear after model upgrades.

Regularly update your CLI tools and read release notes to see which new abilities solve real problems.

6. When agents start “filling in blanks”, quality drops

Agents that must infer missing premises are unstable; once they start guessing, output quality declines. A simple rule helps: before compressing context or restarting a task, have the agent reread the task plan and relevant files.

7. Tasks stop halfway because agents don’t know when they are done

7.1 Humans know “good enough”, agents usually don’t

Agents can start but often lack a clear termination condition, leading to incomplete stubs.

7.2 Tests are a solid termination condition

Specify that the task is complete only when X tests pass, and forbid changing the tests themselves. This makes the stop point concrete.

7.3 Screenshots and verification are becoming usable end conditions

For front‑end or interactive tasks, iterate until tests pass, then capture a screenshot and verify that the UI matches expectations.

7.4 Write termination contracts

Create a {TASK}_CONTRACT.md that lists required tests, screenshots, verification actions, and immutable files. When the contract is satisfied, the agent stops reliably.

8. Longer‑running agents are not necessarily better

Long sessions increase context bloat. Instead of a single endless session, use a contract and start a new session for each distinct task, keeping context clean and drift controllable.

9. Long‑term value comes from rules and skills, not frameworks

9.1 Rules constrain what not to do

Write prohibitive rules in files like coding‑rules.md and have the agent read them before entering a scenario.

9.2 Skills encode how to do things

When a stable procedure emerges, capture it as a skill so the agent can execute it directly.

9.3 Too many rules and skills hurt performance

Excessive rules cause conflicts and further context bloat. Periodic cleanup, merging, and conflict resolution are necessary.

10. You remain responsible for the outcome

Agents are powerful but not autonomous. Design, research, and much of the implementation can be delegated, but the final result must be validated and owned by the human.