The argument over prompt engineering versus context engineering is already stale.
Both camps are fighting over the ground floor of a four-story building.
I run an AI operator company. Ten specialist agents, a routing table, memory, guardrails, thirty-five scheduled jobs that run with no human in the room. When I look at where the actual leverage in my system lives, almost none of it is in the wording of prompts. The prompts are fine. They stopped being the interesting problem a long time ago.
Ten specialist agents, a routing table, memory, guardrails, thirty-five scheduled jobs that run with no human in the room.
This article will explain:
- What each of the four layers actually is (with failure modes)
- A context diagnostic you can run before every agent task
- The loop checklist that lets work repeat until verified
- A four-gate test for whether you need to upgrade layers yet
Anthropic says context engineering is now the art and science of curating what enters an agent's limited context window. Most builders will stop there. That is the expensive mistake.
The frame
Prompt engineering was never fake.
It was just early.
When the chat box was the whole interface, the prompt felt like the product. If the answer was bad, you rewrote the instruction. If the answer improved, you felt like you discovered leverage.
That was layer 1.
Then agents got tools, files, terminals, browsers, memories, background jobs, subagents, and approval gates.
The prompt stopped being the whole system.
It became one small input into a much larger machine.
The developer did not disappear.
The developer moved up the stack.
The 4 layers
Here is the simplest version.
| Layer | Question | Main object | Failure mode | Developer job | | --- | - - | --- | - - | --- | | Prompt engineering | What should I ask? | instruction | vague output | write clearer intent | | Context engineering | What should the model see? | context window | drift and noise | curate the working set | | Harness engineering | What can the agent do safely? | tools, memory, permissions, evals | unsafe or unverified action | build the operating surface | | Loop engineering | How does work repeat until done? | run loop | endless work or false success | define verifier, recovery, and stop rule |
Most people are still optimizing layer 1.
The leverage moved to layers 3 and 4.
The four layers, with failure modes
Layer 1: prompt engineering
Prompt engineering is the skill of converting intent into instructions.
It still matters.
A bad prompt can waste a good model.
But prompt engineering has a ceiling because the prompt is only what you say at the start.
It does not decide:
what files the agent sees what tools it can call what permissions it has what counts as done what happens after failure what gets remembered next time
That is why prompt hacks age so quickly.
They optimize the sentence.
They do not optimize the system.
A strong prompt says:
"Review this PR for correctness and edge cases. Prioritize bugs over style. Return blocking issues first."
That is useful.
But it is not enough if the agent cannot inspect the diff, run tests, compare sibling call paths, or verify the fix.
Prompt engineering is still layer 1.
Just do not confuse layer 1 with the whole stack.
Layer 2: context engineering
Context engineering asks a better question:
not "what should I type?"
but "what should the model know right now?"
Anthropic defines context engineering as curating what goes into the limited context window from a constantly evolving universe of possible information.
That sentence matters.
Context is not a dump.
It is a budget.
Every token you add competes for attention.
A longer context window does not automatically mean better work. It can also mean stale plans, irrelevant logs, old decisions, duplicate docs, and subtle drift.
The job becomes selection.
For coding agents, useful context usually includes:
changed files relevant neighboring files test output project conventions API contracts recent decisions known failure modes explicit constraints
Bad context includes:
full repos when only 5 files matter ancient logs unrelated docs contradictory old plans secrets massive transcripts with no summary
The context engineer is not a prompt poet.
They are the person deciding what world the model wakes up inside.
The context diagnostic
Before asking an agent to work, run this checklist.
| Context item | Include when | Exclude when | | --- | - - | --- | | changed files | the task touches implementation | the issue is only strategic | | neighboring files | conventions or call paths matter | they add no decision value | | tests/logs | failure must be reproduced | logs are stale or unrelated | | docs/specs | behavior is contract-driven | docs conflict with current code | | prior decisions | they constrain the answer | they are just conversation history | | examples | output format matters | examples bias the wrong pattern |
The rule:
load what changes the decision.
exclude what creates drift.
Layer 3: harness engineering
Harness engineering is where most serious agent work lives now.
The harness is everything around the model that makes work repeatable.
Tools. Permissions. Memory. Skills. Tests. Evals. Logs. Checkpoints. Approval gates. Rollback paths. Cost tracking. Observability.
Claude Code's agent loop docs describe programmatic control over tools, permissions, context, sessions, hooks, structured output, and result handling.
Hermes Agent is another example of the same shift: memory, skills, tools, cron, subagents, messaging gateways, and persistent project context turn an agent into an operating layer, not just a chat box.
This is why the product is not the model.
The model is the engine.
The harness is the machine around it.
A weak harness makes a strong model look unreliable.
A strong harness makes a smaller model useful.
What belongs in the harness
Here is the practical map.
| Harness part | What it answers | Example | | --- | - - | --- | | tools | what can the agent touch? | shell, browser, GitHub, email, DB | | permissions | what requires approval? | writes, deploys, messages, payments | | memory | what facts persist? | user preferences, stable environment facts | | skills | what procedures persist? | code review, launch checklist, article workflow | | evals/tests | how is success checked? | unit test, smoke test, metric threshold | | logs/traces | what happened? | tool calls, outputs, cost, decisions | | rollback | how do we undo? | git diff, checkpoint, revert command | | delivery | where does output go? | CLI, dashboard, Slack, Telegram, cron |
If your agent keeps making the same mistake, you do not need a better prompt.
You need the correction to become part of the harness.
Layer 4: loop engineering
Loop engineering is the frontier.
A loop is not "ask the model again."
A loop is a controlled run system:
- define the goal
- load bounded context
- act through tools
- verify the result
- recover from failure
- decide whether to continue
- stop when the condition is true
- save the learning
Claude Code's SDK documentation describes the agent loop as the message lifecycle, tool execution, context window, permissions, turns, budget, sessions, hooks, and result handling that power autonomous agents.
That is the important mental shift.
The agent is not one reply.
The agent is a run.
The developer designs the run.
The loop checklist
If you want an agent to work without turning into chaos, define these before the run starts.
| Loop component | Question | Bad default | Better default | | --- | - - | --- | - - | | goal | what outcome matters? | "improve this" | "make test X pass without changing API Y" | | context | what does it need? | entire repo | relevant files + failing output | | tools | what can it use? | everything | only tools needed for this run | | verifier | how is done checked? | model says done | test, diff, URL, metric, human review | | recovery | what happens on failure? | keep guessing | isolate, hypothesize, retry once, escalate | | stop rule | when does it stop? | when tokens run out | verifier passes or budget is hit | | memory | what persists? | whole transcript | one stable fact or skill patch |
This is where agents become useful.
Not because they can work forever.
Because they know when to stop.
Upgrade path and team mistakes
The layer upgrade path
Most builders should not jump straight to elaborate agent swarms.
Move one layer at a time.
| If you are doing this | Upgrade to this | | --- | - - | | rewriting prompts | save reusable instructions as a skill | | pasting huge context | build a context selection checklist | | trusting outputs | add a verifier | | manually repeating tasks | define a loop | | losing corrections | write memory or patch the skill | | approving blindly | separate drafted, approved, executed, verified |
The most valuable question is not:
"which model should I use?"
It is:
"which layer is failing?"
If the task is misunderstood, fix the prompt.
If the agent is confused, fix the context.
If the action is unsafe, fix the harness.
If the work never converges, fix the loop.
What changes for developers
The old developer workflow was mostly direct manipulation.
You wrote the code.
You ran the test.
You fixed the bug.
You shipped the diff.
The new workflow is more like systems design.
You define the operating boundary.
You decide what the agent sees.
You grant tools carefully.
You create the verifier.
You inspect the trace.
You patch the workflow.
You save the reusable procedure.
That does not make developers less important.
It makes judgment more important.
The cheap work is generating text.
The valuable work is designing the conditions where generated work can be trusted.
The mistake most teams will make
They will buy more intelligence before they build a better loop.
A frontier model can hide a broken workflow for a while.
It can guess better.
It can explain better.
It can recover from more bad setup.
But if the harness is weak, the same problems come back:
context drift unsafe tools missing tests unclear stop rules no memory no audit trail no reusable skill
A better model gives you more capability.
A better loop turns capability into repeatable work.
The article in one table
| Layer | You optimize | Main skill | Output | | --- | - - | --- | - - | | prompt | instruction | clarity | better answer | | context | working set | selection | less drift | | harness | operating surface | systems design | safer action | | loop | repeated run | verification | repeatable work |
That is the shift.
The next developer does not just ask better questions.
They build better conditions.
They decide what the agent sees. They decide what it can touch. They decide how success is measured. They decide what happens when it fails. They decide what gets remembered.
Do you need all four layers yet? Run this test first
Not every task deserves a full loop. A plugin earns its cost only when the work repeats and failure is expensive. Same logic applies here.
Not every task deserves a full loop. A plugin earns its cost only when the work repeats and failure is expensive. Same logic applies here.
| Gate | Question | If no | | --- | - - | --- | | Repeat | Does this task run at least weekly? | layer 1 - 2 may be enough | | Drift | Does output change when context is wrong? | fix context before harness | | Risk | Can a wrong action touch production or users? | add harness gates before looping | | Unattended | Must this run while you sleep? | you need layer 4 with verifier + stop rule |
Miss the repeat gate and a polished prompt is fine. Miss the risk gate and you are not allowed to skip harness work, no matter how good the model is.
Part 5 · Try it yourself (layer diagnostic)
Paste this before your next agent task:
Paste this before your next agent task:
LAYER DIAGNOSTIC
TASK (one sentence):
SUCCESS LOOKS LIKE:
WHICH LAYER IS FAILING?
[ ] prompt - intent was unclear
[ ] context - wrong files or noise in the window
[ ] harness - unsafe tools or no verifier
[ ] loop - work never converges or never stops
FIX ONE LAYER ONLY (pick the checked box above):
NEXT VERIFIER (test, URL, metric, human review):
STOP RULE (when to quit trying):
If you check loop but cannot name VERIFIER and STOP RULE, you do not have layer 4 yet. You have hope.
The close
The cheap work is generating text. The valuable work is designing the conditions where generated work can be trusted.
Prompts age. Context drifts. Harnesses fail open. Loops without stop rules drain budgets. The developer did not disappear when models got good. The work moved up the stack.
your next action: run the layer diagnostic on one task you ran manually twice this week. Fix only the lowest failing layer before you touch model choice.
Which layer is your team still over-investing in while the verifier stays undefined?
I started a private Telegram channel where I share insights and updates regularly: https://t.me/+PE3m-F1jlwVmNjcy
Follow me on X for the daily build in public: @nyk_builderz
Follow @nyk_builderz for AI agent systems, Solana infrastructure, and build-in-public.
- Site: nyk.dev
- GitHub: 0xNyk
- RPC Edge: rpcedge.com