The 2025 and 2026 Agentic AI development only scratched the surface. We learned how LLMs act in agentic environment, how big the context window we can engineer and how many tasks AI agents can take at the time.
But, here’s the problem. Most agent demos work what they’re supposed to, and in production they can burn everything you’ve spent years, if not decades down.
You wire up a model, give it a few tools, put it in a loop, and within an hour you have something that books a meeting or refactors a file or answers a question by searching three sources. It feels like magic. You post the video.
Then you put it in front of real users with real data and it falls apart in ways the demo never hinted at. It loops forever on a task it can’t complete. It hallucinates a tool call. It performs beautifully for twenty steps and catastrophically on step twenty-one, and you have no way of finding out which step twenty-one was.
Many will say that this happens because the model is not as good, or it’s not fine-tuned well. Wrong! It’s an engineering loophole — a specific set of design problems that don’t exist in traditional software and don’t get solved by a better prompt.
In this guide, we’ll discuss the tools and skills you should know now, whether you’re a data scientist or data, AI, or software engineer, as well as which concepts you should master before 2027 if you want to remain relevant in your field.
The skills, tools and other concepts you should understand now. If any of these are fuzzy, the ten sections below will be harder than they need to be.
Agent — a model in a loop with tools. Not a chatbot, not a workflow. The defining property is that it decides its own next step.
Tool call — the model returning a structured request to run a function, rather than returning text. Everything an agent does happens here.
Trajectory — the full sequence of steps a single task took. The unit you debug and evaluate, as opposed to a single input/output pair.
Context window — the working memory of one model call. Finite, expensive, and refilled from scratch every step.
MCP (Model Context Protocol) — the open standard for connecting agents to tools and data sources without writing a bespoke integration each time.
Sub-agent — a delegated agent with its own context window that does bounded work and returns a result.
RAG — retrieval-augmented generation. In agent terms: retrieval becomes a tool the agent chooses to call, not a step you hardcode.
Tools worth knowing by name:
Frameworks: LangGraph (the production default for stateful workflows), OpenAI Agents SDK and Claude Agent SDK (lighter, vendor-native), CrewAI (fastest to a multi-agent prototype), Pydantic AI (type-first)
Observability & evals: Langfuse (open-source, self-hostable), LangSmith (deepest LangChain integration), Braintrust (eval-first), Arize Phoenix (OpenTelemetry-based)
Execution: MCP servers for tool access, sandboxed runtimes like E2B or Modal for anything that executes code
You don’t have to be an expert at all of these tools to be relevant. However, you need to know which box each one fills because most stack decisions are really just a framework, an observability layer and a sandbox.
If you want a full list of tools and skills I use as a data scientist and AI consultant, check this guide I wrote last week with examples.
The harness is everything outside the model that makes action possible. The sandbox it runs in, the file system it can read and write, the shell it can call, the runtime boundaries, the way results come back to it. If the model is the brain, the harness is the body and the room.
Most teams spend their time on the prompt and almost none on the harness, then attribute the resulting failures to the model. But an agent asked to fix a bug, with no ability to run the test suite, isn’t reasoning badly — it’s reasoning blind. It has no feedback signal. It’s guessing, confidently, because guessing is all the environment permits.
There are several design questions like “Can the agent observe the consequences of its actions? Can it verify its own work before declaring success? Can it recover from a bad step, or does one mistake poison everything downstream?”
Every capability you want the agent to have needs a corresponding way for the agent to check whether it worked. Capability without verification is just a faster way to be wrong.
An agent is a model in a loop, which means the loop is where a surprising amount of your design lives. It’s also the part most people copy verbatim from a tutorial and never look at again.
The whole thing turns on two questions — when does it run again, and what makes it stop — and the failure modes fall out of getting those wrong.
The first is the infinite loop, where the agent keeps attempting slight variations of the same failing action because nothing in the system ever tells it to stop trying. The second is premature termination, where it announces completion at sixty percent because the stop condition was, in effect, “the model says it’s done.” The third is the expensive one: thrash. The agent oscillates between two approaches, each time convinced the other one was the problem, burning tokens on a task it structurally cannot finish. All three are cheap to produce and painful to discover on a monthly bill.
What prevents them is unglamorous. An explicit iteration ceiling. A cost ceiling enforced in code rather than requested politely in the prompt. Some cheap signal of progress — a hash of the working state, a count of resolved subtasks — so that “nothing has changed in four steps” is a condition your system can detect rather than a pattern only a human reading the logs would notice.
And, most importantly, an escalation path. Agents fabricate when failure isn’t an available option. If the only way for a trajectory to end is with a success message, the model will produce one. Give it a legitimate way to say I can’t do this, here’s how far I got, here’s what’s blocking me — and much of what looks like hallucination stops happening. An agent that has no way to fail cleanly will fail expensively instead.
The context window is a budget, not a bucket. Context engineering is the discipline of spending it well: getting the right information in, and — the half people forget — keeping the wrong information out.
This is where long-running agents die, and they die slowly enough that it’s hard to see happening. Every tool call returns something. Every step appends to the history. Thirty steps in, the window holds stale search results, three superseded plans, and error messages from problems that were solved twenty minutes ago. The relevant signal is still in there, buried under twenty thousand tokens of noise. And the model’s decisions get measurably worse — more information, worse performance, which is the opposite of the intuition most engineers bring to the problem.
The techniques for managing it are all versions of the same idea: stop treating the window as a place where things accumulate. Retrieval gets information in just-in-time instead of preloading it in case it’s needed. Compaction summarizes the trajectory when it crosses a threshold and continues from the summary rather than the raw history. Sub-agents do a bounded piece of work in their own window and hand back only the conclusion, so the exploration cost never touches the parent’s budget. And externalized notes let the agent write structured state to a file it can re-read, which means memory doesn’t have to live in the conversation at all.
The useful mental discipline: treat every token in the window as something you deliberately chose to put there. If you can’t say why it’s there, it’s costing you — in money, and in the quality of the next decision.
An agent is exactly as capable as the tools you hand it, and exactly as safe as their worst edge case. Tools are its entire interface with the world, which makes this one of the highest-leverage and least-discussed parts of the job.
The near-universal mistake is treating tool design as an API-wrapping exercise. You have forty endpoints, so you expose forty tools, each carrying the description you’d write for a human developer reading docs. Then the agent picks the wrong one, or gets lost between three that overlap, or calls the right one with arguments that don’t quite parse. The instinct is to blame the model’s tool-calling ability. Usually the tools were just badly written.
What works is remembering that tool descriptions are prompts, and writing them accordingly — unambiguous names, explicit scope, and a clear statement of when not to reach for this one. Consolidation helps more than people expect: a single well-designed search_customers beats six near-identical lookup endpoints, because now there’s no selection problem to get wrong. Errors should teach recovery rather than merely report failure; “no results, try widening the date range” changes the agent’s next move, while “400 Bad Request” doesn’t. And the shape of what comes back matters as much as whether it’s correct, because a tool that returns ten thousand tokens of nested JSON has just spent your context budget on the agent’s behalf without asking.
The test I’d apply: if a competent new hire would need to ask a clarifying question before using your tool correctly, the model will need one too — and unlike the new hire, it won’t ask.
Memory is what survives when the context window doesn’t — across steps, across sessions, across users.
Almost the entire engineering conversation about memory is about retrieval: embeddings, vector stores, hybrid search, reranking. But retrieval is the easy half. The hard half is the write path, and it’s the part almost nobody designs on purpose.
Ask what’s actually worth remembering and the answer is narrower than it first appears. Decisions and the reasoning behind them, yes. Stated constraints and preferences, yes. The transient state of step seven of a task that finished last Tuesday, no. Without a deliberate write policy, memory becomes a junk drawer — everything goes in, retrieval starts returning three useful items alongside seven irrelevant ones, and agent behaviour degrades in a way that is genuinely difficult to trace back to its cause. The symptom shows up as bad reasoning. The disease is in what got stored six weeks earlier.
The questions that matter are policy questions, not infrastructure ones. What gets written, and on what trigger? What decays, and after how long? What happens when new information contradicts something already stored — is the old fact overwritten, marked superseded, or silently duplicated so that retrieval now surfaces both and the model has to guess? And who can see it: is this memory scoped to a user, a team, or the entire system, and are you certain about that answer?
A memory system without a forgetting policy isn’t a memory system. It’s a log with a search bar.
Orchestration is the structural question of how many agents you have and how they relate to each other. Single agent. Planner and executor. An orchestrator with parallel workers. Evaluator-optimizer loops. Full swarm.
It is also the most over-applied idea in the field right now, largely because it’s the most satisfying to diagram. Every additional agent adds coordination cost. Context has to be handed between them and something is always lost in the handoff. Work gets duplicated because two agents independently decided the same subtask was necessary. And two agents writing to shared state concurrently is a category of bug you did not previously have and are not set up to debug.
The heuristic that survives contact with production is simple: parallelize reads, serialize writes. Fanning out five sub-agents to research five sources at once is excellent — they’re read-only, their outputs merge cleanly, and the speedup is real. Fanning out five sub-agents to edit five parts of the same codebase is a merge conflict with extra steps and a substantially larger bill.
So the honest default is one agent with excellent tools, and you reach for multi-agent when you can name the specific parallelism you’re buying and you’ve priced the coordination overhead against it. “It felt more sophisticated” is not a reason.
At some point your agent will attempt the thing you didn’t want it to do. Guardrail design is the work that makes that survivable rather than catastrophic.
The first layer is blast radius, and it’s mostly a set of decisions you make once and benefit from forever. Least privilege by default: scoped credentials, not the admin key that happened to be in your environment variables. Allowlists rather than blocklists, because you can enumerate what should be permitted and you cannot enumerate what shouldn’t. Irreversible actions behind an explicit approval gate — sending external email, deleting records, moving money, deploying to production. The question isn’t whether the agent will eventually do something wrong. It’s what the worst thing it can do is, and whether you’re comfortable with that number.
The second layer is prompt injection, and it stops being a theoretical concern the moment your agent reads anything it didn’t generate itself. A support ticket. A web page. A PDF. An email. All retrieved content is untrusted input, and instructions embedded in it will be read by a model that has no reliable way to distinguish “content I was asked to summarize” from “instructions I was given.” An agent that can read untrusted content, access private data, and communicate externally is a data exfiltration path waiting for someone to find it — and the three capabilities are individually innocuous, which is exactly why the combination gets built by accident.
The mindset that leads to good design here is assuming the model will be successfully manipulated at some point, because occasionally it will be. Once you accept that, the interesting question changes from “how do I prevent it” to “what can the manipulation actually reach,” and that’s a question you can engineer an answer to.
Measurement is harder for agents than for anything else you’ve built, and the reason is structural rather than incidental.
Traditional software testing assumes determinism: same input, same output, assert equality. Agents violate both halves of that. The output isn’t a value — it’s a trajectory, a whole sequence of decisions and tool calls and recoveries. And the same input won’t produce the same trajectory twice, so a test that passed this morning can fail this afternoon without anything having changed.
What replaces it is a layered approach. End-state assertions carry the most weight: forget how it got there, did the row get created, is the file correct, did the right email go out. That’s the most robust signal available and it’s the one that maps to what users actually care about. Underneath that sit step-level checks for the invariants — the agent never called the delete tool, never exceeded fifteen steps, never blew past the budget cap. For the genuinely fuzzy dimensions, whether a summary is faithful or a response is appropriately hedged, LLM-as-judge with an explicit written rubric works well enough to be useful, provided you’ve validated the judge against human ratings at least once.
Two things distinguish teams who do this well. They run each case multiple times and track pass rate rather than pass/fail, because a single run of a stochastic system tells you close to nothing. And they build their regression suite out of real failures — every production incident becomes a permanent test case. That second habit is the highest-value eval work available and it costs almost nothing to start.
Which is the point worth ending on: twenty real cases from your actual users beat two hundred synthetic ones. You can start that this afternoon, before you’ve chosen a framework or built any infrastructure at all.
The question was never whether to keep a human involved. It’s where to put the checkpoint.
The naive answer is to gate everything, and it fails in a way that’s easy to predict and hard to notice. Ask someone to approve twenty actions an hour and by the third hour they’ve stopped reading and started clicking. Approval fatigue produces a system that looks supervised and isn’t — which is meaningfully worse than having no gate at all, because now the oversight is theatre and the whole organization believes in it.
The criterion that actually holds up is reversibility. Automate freely whatever you can undo; escalate whatever you can’t. A draft is reversible, a sent email isn’t. A local commit is reversible, a production deploy isn’t. A staged transaction is reversible, a settled one isn’t. This maps to real risk far better than confidence thresholds do — and confidence thresholds have the additional problem of asking the model to assess its own reliability, which is precisely the thing it’s worst at.
Two implementation details matter more than they sound like they should. Batch your approvals, so the human reviews a coherent unit of work instead of a stream of interruptions arriving at random intervals. And show diffs rather than descriptions: a person approving “I’ll update the configuration” is approving something quite different from a person looking at the four lines that actually changed. The first is a vibe check. The second is review.
Every gate you add makes the remaining ones slightly less effective, because attention is finite and you’re spending it. Spend it where the error would be permanent.
This one is last on the list and it’s the one I’d build first.
When your agent fails at step fourteen of thirty, you need step fourteen: the exact prompt that went in, the tool it chose, the arguments it passed, what came back, the tokens it burned, the latency, the cost. Without that, your debugging loop is re-running the task and hoping it fails the same way — and it won’t, because nothing about this system is deterministic. You end up forming theories you can’t test about behaviour you can’t reproduce.
Instrumentation means a span per step with full input and output captured, token count and latency and cost recorded at both the step and task level, tool call success and error rates broken down per tool, and steps-per-task tracked as a distribution rather than an average — the tail is where your money goes, and averages hide tails by design. Replay is the capability that repays the effort fastest: being able to take a captured failure and re-run it against a modified prompt or a different model turns debugging from archaeology into experimentation.
And the aggregate view matters as much as any individual trace, because it answers the question every agent team eventually faces at an uncomfortable moment: did our success rate drop because of the prompt change we shipped on Tuesday, or because the underlying model was updated underneath us? Without historical traces you cannot answer that. With them, it’s a query.
You cannot improve what you cannot replay.
If you’re working through these, the order that matters isn’t the order they’re listed in.
Most people are stuck on 3 and 4 which are context and tools. That’s where the tutorials live, that’s where improvement is most visible, and to be fair, that’s genuinely where a lot of agent quality comes from.
But the gap between a demo and a system is 7 through 10. Guardrails, evals, human-in-the-loop, observability. Nobody makes content about these because they don’t demo well — there’s no compelling thirty-second video of an eval suite. They’re also the entire explanation for why some teams have agents running in production and others have a very impressive prototype that’s been two weeks from launch since March.
Pick whichever one you’re weakest at and build the smallest useful version of it this week.
If you’re still learning, I can help guide you because the journey to master AI is everything but linear. No matter which background you’re coming from, being technical is never the wrong decision.
Here are resources to check:
The ultimate ML/AI Engineer roadmap with curriculum guidance, AI projects, tools and career guidance that’s evergreen.
Agentic Intelligence - a must-have book that walks you through talking to LLMs, to fine-tuning and optimizing multi-agent AI systems.
See you next week!
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.