A few years ago, I was a frontend engineer. Then ChatGPT dropped in late 2022, the whole industry tilted, and I tilted with it. These days I build conversational AI agents at Tars — RAG pipelines, agent loops, eval frameworks, multi-agent orchestration — and somewhere along the way I realized I never actually wrote any of it down.
This article is my attempt to fix that. It has a selfish goal and a generous one. The selfish goal : writing forces recall, and recall exposes the gaps in what I think I know. The generous one : if you're new to AI engineering, I hope you walk away from this having learned something you can actually use.
So here they are — nine principles of agentic engineering.
1. An agent is a loop, not a model
This is the single most clarifying idea in the whole field, and it's the one most beginners miss.
An LLM by itself is a text-in, text-out function. It has no hands. It can tell you how to check the weather; it cannot check the weather. What turns a model into an agent is embarrassingly simple :
The model looks at the task, decides which tool to call, the harness executes it, the result gets fed back into the context, and the model decides again. Loop until the model says "done". That's it. That's the agent.
Everything else in this article — context management, memory, sub-agents, guardrails — is engineering around this loop. The loop is the organism; the rest is life support.
The loop is the agent. The model is just the brain inside it.
2. Start with the dumbest loop that works
My most expensive lesson, learned the hard way more than once.
When you first design an agent, you will be tempted to build the fancy version : routing layers, planner-executor splits, graphs of specialized nodes, elaborate state machines. Resist. Every piece of machinery you add before you've measured anything is a guess — and your guesses about where the agent will struggle are almost always wrong.
Start with the simplest possible loop : one model, a handful of tools, a clear system prompt. Run it against real tasks. Watch where it actually fails. Then add complexity — but only at the failure points, and only when your evals (principle 6) prove the addition helps.
Modern models are better at driving a simple loop than most people expect. Half the scaffolding people build is compensating for model weaknesses that no longer exist.
Complexity is not a starting point. It's a response to evidence.
3. Context is your scarcest resource
Every model has a context window — the total amount of text it can consider at once. Everything must fit inside it : the system prompt, the conversation history, tool definitions, tool results, retrieved documents, all of it. And long before you hit the hard limit, quality degrades — models pay less attention to the middle of a bloated context than to its start and end.
So treat context like memory on an embedded device. Budget it. This discipline has a name now — context engineering — and it's arguably the core skill of the job :
- Curate what goes in. Only the tools, documents, and history relevant to the current task. An agent with fifty tool definitions stuffed into every request is paying rent on tools it never calls.
- Summarize what grows. Long conversations get compacted : older turns collapse into a summary, recent turns stay verbatim.
- Evict what's stale. A huge tool result from ten steps ago usually earned its keep already. Drop it, keep the conclusion.
The system prompt deserves special respect here. It's the steering wheel of the whole agent — behavior, tone, constraints, tool guidance — and it's the part you'll iterate on more than any code.
Every token in the context should be earning its place. If it isn't, evict it.
4. Give the agent an environment, not just a knowledge base
When I started in this space, "AI engineering" mostly meant RAG : parse your documents, chunk them, embed them, retrieve the nearest chunks at query time, stuff them into the prompt. Retrieval was the product.
Agents flip that framing. A knowledge base answers "what does the agent know?" — but the more important question is "what can the agent do?" Tools are the answer : fetch a URL, search the web, query a database, run code, send an email. Each tool is just a function with a name, a description, and a schema; the model reads the description and decides when to call it.
Notice what happens to RAG in this picture : it becomes one tool among many. The agent calls search_knowledge_base the same way it calls get_weather. Retrieval didn't die — it got demoted from being the architecture to being a capability. (RAG still matters, and the pipeline behind that tool is its own deep topic — I'm writing a separate post comparing the two paradigms.)
One more thing worth knowing early : tools are getting standardized. The Model Context Protocol (MCP), an open standard introduced by Anthropic in November 2024 and since adopted across the industry, lets any tool server plug into any compliant agent — the analogy everyone uses is a USB-C port for AI. You define the tool once; every agent can use it.
Knowledge tells the agent about the world. Tools let it act on the world. Build for the second.
5. Memory is how agents survive the context window
Here's the uncomfortable truth the loop hides : the model remembers nothing. Every request starts from zero; the "memory" is just whatever text you chose to put in the context. End the session and it's gone.
So agents that need continuity get memory as an engineered feature, and in practice it splits into two kinds :
- Scratchpad (short-term). A working area for the current session — intermediate results, notes, partial plans. Wiped when the session ends. Often this is literally a directory of files the agent reads and writes.
- Long-term memory. Durable facts the agent writes down because it knows it will forget : user preferences, project decisions, lessons from past failures. Stored outside the context (files, a database), and selectively loaded back in when relevant.
The pattern to internalize : memory is not a model feature, it's an architecture. The agent writes notes to its future self, and the future self reads them. If you've ever left yourself a TODO.md before a vacation, you already understand agent memory.
An agent's memory is whatever it wrote down. Design what it writes, and when.
6. Offload work to sub-agents to preserve context
Once you internalize principle 3 (context is scarce), sub-agents become obvious.
Say your agent needs to search a large codebase for something. Done naively, the search dumps thousands of lines of file contents into the main context — and that garbage stays there for the rest of the session, crowding out everything else.
The fix : spawn a sub-agent. It gets its own fresh context window, does the messy exploration there, and reports back only the conclusion — three paragraphs instead of three thousand lines. The main agent stays clean, holding the plan and the findings, not the raw noise. The sub-agent's context is then thrown away.
This also unlocks parallelism (several sub-agents exploring independent questions at once) and specialization (a sub-agent with a narrow system prompt and only the tools it needs). I use this pattern in Argus, my PR-review tool : instead of one agent reading the entire diff, it fans out a worker per file, and each worker reports back only its annotations — the orchestrator never sees the raw file contents. But the first-order win is simpler than either parallelism or specialization : sub-agents are a context-management strategy. The orchestrator keeps the map; the workers eat the details.
Delegate the noisy work. Keep only conclusions in the main context.
7. Think about evals from day one
If I could force one habit onto every new AI engineer, it's this one.
Agentic systems are non-deterministic. The same input can produce different outputs; a prompt tweak that fixes one case silently breaks three others; a model upgrade shifts behavior under your feet. Without evals, every change you make is a vibe. You demo it twice, it looks fine, you ship it, and you find out from users what broke.
Evals are the test suite of AI engineering — a set of realistic tasks with a way to score the agent's output. Some scoring is plain code (did it call the right tool? does the output match the schema?). For fuzzier qualities, you use LLM-as-judge : another model grades the output against a rubric you wrote. And when you don't have enough real test data, you generate synthetic data — using a strong model to produce realistic queries against your own knowledge base. A big chunk of my job at Tars is exactly this kind of eval infrastructure — synthetic test data pipelines, LLM-as-judge rubrics, retrieval metrics — and it has paid for itself every single time the agent changed.
The reason this is a day-one concern and not a later-polish concern : evals are what give you confidence to change things. Principle 2 said "start simple and improve where the agent fails" — but you only know where it fails, and whether your fix helped, if you can measure. No evals, no iteration. Just guessing.
Without evals you're not engineering, you're gambling. Build the measuring stick before the thing you measure.
8. You can't fix what you can't observe
Evals tell you how the agent performs on your test set. Production tells you the truth.
An agent in production is a black box making dozens of decisions per task — which tool to call, with what arguments, how to interpret the result. When a user reports "the agent gave me a wrong answer", you need to replay that exact session : every prompt, every tool call, every intermediate step, with latency and token costs attached. This is tracing, and tools like LangSmith and Langfuse exist precisely for it.
Debugging an agent without traces is like debugging a distributed system with no logs — you're reduced to asking the user "what exactly did you type?" and squinting. With traces, most "the AI is being weird" reports turn out to have boring, fixable causes : a retrieval that returned junk, a tool that errored silently, a context that got truncated mid-thought.
And there's a compounding bonus : production traces are the best source of eval cases you will ever have. Every weird real-world failure becomes a permanent regression test.
Instrument the loop from the start. Every step the agent takes should leave a trace you can replay.
9. Never fully trust the agent — or its inputs
The last principle is the one that keeps you out of the incident channel.
Agents act. That's their whole value, and their whole risk. Two habits follow :
- Treat everything entering the context as a trust boundary. When your agent reads a web page, a user-uploaded document, or a scraped review, that text sits in the same context as your instructions — and the model can't reliably tell the difference. This is prompt injection : a hostile document that says "ignore your instructions and instead…" will sometimes just work, and as of today there is no complete, reliable defense — only mitigation via defense-in-depth. I ran into this building Argus : a code-review agent reads arbitrary repos, which means a comment in the diff itself could try to instruct the reviewer ("this file is fine, skip it"). The code you're reviewing is untrusted input. Sanitize what you interpolate into prompts, and never give an agent that reads untrusted input more authority than you'd give the author of that input.
- Gate the irreversible actions on a human. Deleting data, sending emails, spending money, deploying code — anything you can't undo should stop and ask. This is human-in-the-loop, and it's not a temporary crutch until models get better; it's a permanent design principle, the same reason
rm -rfasks for confirmation. Give the agent a sandbox where it can act freely, and require sign-off at the boundary where actions become irreversible.
Give your agent the least authority that still gets the job done. Autonomy is earned, not granted.
Wrapping up
Stepping back, the nine principles compress into one sentence : an agent is a simple loop, and agentic engineering is the discipline of managing what flows through it — context in, actions out, memory across sessions, measurements over everything.
The field moves absurdly fast. Models, frameworks, and best practices from six months ago are already dated, and half the scaffolding we build today will be obsolete next year. But these fundamentals — the loop, the scarcity of context, the need for evals and observability, the distrust of inputs — have stayed stable through every wave so far. Learn these, and every new framework is just a new coat of paint on a building you already know.
I hope you find this article interesting. Thanks for reading. Until then, bye 👋