The AI Engineering Concepts I Wish Someone Explained Simply

It’s fascinating how AI is changing the day-to-day work of software engineers.

We used to spend a lot of time learning syntax (or should I say memorizing it? haha) and understanding the abstractions behind frameworks and libraries.

Then AI-assisted coding became part of our daily work, and we started hearing about the "vibe coding": using AI to build something while focusing mostly on the outcome, sometimes without paying enough attention to the bigger picture—architecture, reliability, security, and best practices.

Then came agentic coding, which I think is where many developers are right now: using agents to generate code, navigate repositories, run commands, and help implement changes.

Now there’s this idea of Agentic Engineering, which goes a bit further. Instead of just asking an agent to write code, it's about optimizing our day-to-day work by delegating tasks to agents that are configured with the right context.

I was watching an IBM video about Agentic Engineering linked in this article, and one idea that stuck with me was this shift from writing to shaping.

Instead of writing everything ourselves, we start shaping the environment around agents—defining rules, skills, context, tools, and what we actually expect from them - so they can work in sync with what we need. And IMO, this is where the future of software engineering is going.

Agentic Engineering goes way beyond just writing code. With the right setup and context, you can have agents handle many of the tasks that are part of your everyday engineering work. Need to understand what happened with a specific request? Have an agent investigate the logs. Want to check if an implementation actually follows the tech spec? Let an agent compare them. Need to investigate a bug, review some code, or figure out why something isn't working as expected? Those are tasks you can delegate to an agent too.

The idea is simple: instead of using agents only to write code, you can use them to do the engineering work around the code. The interesting part is that our job starts becoming less about writing everything ourselves and more about shaping how the work gets done.

But once you start exploring this, you run into a bunch of terms: agents, tokens, context engineering, skills, MCP, orchestration... and it isn't always obvious what each one means or how they fit together. And that's exactly why I wanted to write this post.

I've been learning about these concepts while exploring different tools and ways of working with AI, and I realized that some of them sound way more complicated than they actually are.

So I decided to put together a glossary of the AI Engineering concepts I think every SWE should at least be familiar with. Nothing too academic or overly technical, just simple explanations, practical examples, and how these concepts connect to each other.

Let's get into it!

---

1. The Foundation

LLM (Large Language Model)

An LLM is a type of AI model trained on large amounts of data to understand and generate language. At its core, it works by predicting tokens based on the context it receives. That might sound simple, but this ability allows LLMs to write code, explain complex topics, summarize documents, reason through problems, and much more.

Think of an LLM as the engine behind tools like ChatGPT, Claude, and other AI assistants.

Models

You've probably heard names like GPT, Claude, Gemini, or DeepSeek. These are different families of AI models, developed by different organizations, with different capabilities, limitations, and costs.

And choosing a model isn't always about picking the "smartest" one. Some models are better at complex reasoning, others are faster, cheaper, or more suitable for specific tasks.

For example, you probably don't need the most expensive reasoning model just to summarize a log file. But investigating a complex issue across multiple services might benefit from a more capable one.

If you're curious about how models compare in terms of performance, pricing and speed, Artificial Analysis is a useful resource.

System One Models (Jev)

Here's something interesting: not every AI model is designed to generate text.

In September 2026, TypeSafe AI announced Jev, a different kind of model they call a System One Model.

While traditional LLMs generate text token by token, Jev is designed to make fast, structured decisions. Instead of asking it to write an explanation, you provide some information and define the possible answers. The model then returns a structured decision with scores that can help the application evaluate the result.

For example, imagine you're building a system that processes incoming support tickets. Instead of asking an LLM to read every ticket and generate a response explaining which team should handle it, you could use Jev to classify the ticket directly into categories like billing, technical, or account.

And because the possible outputs are defined in advance, your application can use the result without having to interpret free-form text. The interesting part is that Jev doesn't generate text autoregressively like traditional LLMs. It's designed to produce structured decisions in parallel, making it potentially faster and cheaper for certain constrained decision tasks. Those benefits depend on the workload and should be benchmarked rather than assumed.

Of course, this doesn't mean it replaces LLMs. You wouldn't use Jev to write an entire application or explain a complex architecture. Think of general-purpose LLMs as flexible language engines and Jev as an example of a model designed for constrained decisions. “System One Model” is TypeSafe AI’s terminology here, not a universally adopted model category.

And this is another reason why choosing the right model for the right task matters.

Tokens

Tokens are the units of text that language models process. A token isn't necessarily a word. It can be a whole word, part of a word, punctuation, or even whitespace.

For example, a sentence might be split into several tokens depending on the model's tokenizer. Why does this matter?

Because tokens affect cost, performance, and how much information a model can process. When you send a prompt, include documentation, attach logs, or receive a response, you're consuming tokens. That's why dumping thousands of lines of logs into an agent isn't always the best idea.

Context

Context is the information available to a model when it's generating a response. It can include your instructions, conversation history, source code, documentation, logs, tool results, and anything else provided to help it understand the task. For example, imagine asking an agent: Why is this API request failing?

Without context, the model can only make assumptions or suggest generic debugging steps. But if you provide relevant logs, architecture documentation, and request details, it has a much better chance of finding the actual problem. And this leads to something we'll explore later: Context Engineering.

Context Window

The context window is the maximum amount of information a model can process at once, measured in tokens.

Think of it as the model's available working space. Your instructions, conversation history, code, documentation, and tool responses all compete for that space.

And here's something important: a larger context window doesn't automatically mean better results. Even when a model can technically handle a huge amount of information, irrelevant or poorly organized context can make it harder to find what's actually important.

That's one of the reasons why managing context becomes so important when working with agents.

---

2. Anatomy of an AI Agent

Now that we've covered the basics, let's talk about agents.

We've been using this word a lot, but what actually makes something an agent? And how is it different from simply asking ChatGPT a question?

To understand that, let's break down the concepts behind an agent, how it works, and how agents can collaborate with each other.

Agent

An AI agent is a system that uses an AI model to work toward a goal, make decisions about what to do next, and interact with tools or its environment to accomplish a task.

The important part here is that an agent doesn't just generate a response. It can take actions.

For example, when you ask an LLM to investigate a bug, it might suggest where to look or what could be causing the problem. But an agent with the right tools and permissions could actually inspect the code, search through logs, run tests, identify a possible cause, and suggest or implement a fix.

And it doesn't necessarily have to follow a fixed sequence of steps. Based on what it discovers, it can decide what to investigate next. Of course, that doesn't mean agents are always correct or should have unlimited permissions. Their work still needs appropriate boundaries and verification.

But here's something interesting: agents can also delegate work to other agents. And that's where subagents come in.

Subagent

A subagent is simply an agent that receives a task delegated by another agent or a coordinating system. Think about how we work in engineering teams.

When you're investigating a complex issue, you might ask another engineer to check the logs while you inspect the code. You're both working toward the same goal, but focusing on different parts of the problem. Agents can work in a similar way.

For example, imagine an agent investigating why an API request is failing. Instead of doing everything itself, it could delegate:

• Log analysis to one subagent.
• Code inspection to another.
• Documentation review to a third.

Each subagent works on its assigned task and returns its findings to the main agent, which can then combine the results. A subagent isn't necessarily a different kind of AI. It's still an agent, but operating as part of a delegated workflow.

It might use the same model as the main agent, a different model, or even have a completely different set of tools and instructions. And depending on the system, subagents can work sequentially or in parallel.

Scout

A scout is an agent specialized in exploration, research, or gathering information.

The term isn't universally standardized, so its exact meaning can vary depending on the tool or framework you're using. But the general idea is simple: instead of having the main agent explore everything, you delegate the discovery work to a scout.

Imagine you're working in a large codebase and need to understand how authentication works. You could ask a scout to:

• Find the files responsible for authentication.
• Identify the relevant services and dependencies.
• Locate related technical documentation.
• Report how the authentication flow is implemented.

The scout explores the codebase and returns a summary of its findings. This can help the main agent focus on the actual task without having to perform every investigation itself. And here's an important distinction:

Subagent describes the relationship between agents. Scout describes what an agent specializes in.

A scout can be used as a subagent, but it doesn't necessarily have to be one.

Persona

A persona defines the role, behavior, or perspective we want an agent to adopt.

For example, you might configure an agent to behave like a senior backend engineer, a security reviewer, an SRE, or a technical lead. But a persona isn't just saying "You are a senior engineer" and expecting magic to happen. 😅

A useful persona can also define responsibilities, constraints, priorities, and how the agent should communicate its findings. For example, an SRE-oriented persona might instruct an agent to:

• Prioritize evidence from logs and metrics.
• Avoid making production changes without approval.
• Clearly distinguish confirmed findings from hypotheses.
• Provide a structured incident investigation report.

But here's something that can be confusing at first: A persona isn't the same thing as an agent.

Think of it this way:

• Agent: The system that performs the work.
• Persona: The role and behavior assigned to that system.

You could have two agents using exactly the same LLM but with different personas, tools, and responsibilities. One might act as a code reviewer, while the other acts as an incident investigator.

And depending on the framework, a persona might be defined in a Markdown file, a system prompt, or another configuration format. But simply creating a persona doesn't necessarily create a new runnable agent. That depends on how the system is configured to load and execute agents.

Tools

Tools are what allow agents to interact with the world outside the model.

An LLM by itself doesn't automatically have access to your terminal, filesystem, databases, APIs, or monitoring systems.
But when connected to tools, an agent can perform actions such as:

• Reading and editing files.
• Running terminal commands.
• Searching documentation.
• Querying logs and databases.
• Calling external APIs.
• Executing tests.

For example, imagine an agent investigating a production issue. It might use one tool to search application logs, another to inspect the relevant source code, and another to retrieve technical documentation.

The model can select actions, while tools provide the capabilities to carry them out.

Of course, the agent can only use the capabilities exposed to it, and those capabilities should be restricted according to the task and required permissions.

Tool Calling

Okay, but how does an agent actually use those tools? That's where tool calling comes in.

Tool calling is the mechanism that allows a model to request the execution of a tool, usually by producing a structured call containing the tool name and its arguments. The application running the agent receives that request, executes the tool, and returns the result to the model. For example, imagine asking an agent:

Find out why request ABC failed.

The process might look like this:

1. The model decides it needs to search the logs.
2. It generates a tool call to query the logging system.
3. The agent's runtime executes that call and returns the results.
4. The model analyzes the logs and decides what to investigate next.
5. If necessary, it makes additional tool calls until it has enough information to provide an answer.

This process can repeat multiple times until the agent reaches a conclusion, encounters a limit, or needs human input. One important detail: the model doesn't execute the tool itself. The surrounding software handles the execution.

And this distinction becomes important when we talk about Agent Harnesses.

Agent Harness

This is one of those terms that sounds more complicated than it needs to be.

An agent harness is the software environment around the model that makes agentic behavior possible. Remember when we talked about tool calling?

The model can request a tool, but something needs to actually execute it, return the result, manage the conversation, and determine when the agent should continue or stop.

That's part of what the harness does. Depending on the implementation, a harness can manage:

• The agent's execution loop.
• Tool availability and execution.
• Context and conversation history.
• Permissions and safety boundaries.
• State and persistence.
• Error handling and retries.
• Delegation to other agents.

Think of the model as the reasoning engine and the harness as the system that allows that engine to operate.

The same model can behave very differently depending on the harness it's running in.

And that's an important idea because improving an agent isn't always about switching to a more powerful model. Sometimes, improving the environment around it makes a bigger difference.

Orchestration

Now that we know agents can delegate work to subagents, how do we coordinate everything?

That's where orchestration comes in. Orchestration is the process of coordinating tasks, agents, tools, and their results to accomplish a larger goal.

Imagine you're investigating a production incident involving multiple services. Instead of having one agent investigate everything sequentially, you could organize the work like this:

1. A main agent analyzes the incident and creates an investigation plan.
2. A scout explores the codebase to identify the relevant services.
3. Another subagent searches logs for errors related to the incident.
4. A third subagent checks recent deployments and changes.
5. The main agent collects their findings, compares the evidence, and decides whether more investigation is needed.
6. Finally, it produces a report explaining the likely root cause and supporting evidence.

That's an example of a multi-agent workflow. But orchestration doesn't necessarily require multiple agents. It can also coordinate tools and tasks within a single-agent workflow. And here's another important distinction: Orchestration isn't an agent or a persona. It's the coordination of the work.

You can have an agent responsible for orchestration, often called an orchestrator agent, with a persona that defines how it should plan, delegate, and validate tasks.

Orchestration can also be handled by the harness or by predefined application logic. So, to summarize:

• Agent: The system doing the work.
• Subagent: An agent working on a delegated task.
• Scout: An agent specialized in exploration and information gathering.
• Persona: The role and behavior assigned to an agent.
• Orchestration: How tasks and agents are coordinated.

And the interesting part is that these concepts can work together. An orchestrator agent can have a technical lead persona, delegate investigations to scouts and other subagents, and use tools to validate their findings. All of this without requiring every agent to use the same model or have the same capabilities.

---

3. Engineering the Agent's Environment

So, we have models, agents, tools, and a harness that connects everything together.

But here's the thing: having a powerful model and a bunch of tools doesn't automatically mean you'll have a useful agent.

The agent still needs to understand your project, know where to find information, follow your team's conventions, and have clear instructions about what it's supposed to do.

And this is where some of the most interesting AI Engineering concepts come in.

Prompt Engineering

You've probably heard this one a thousand times already. Prompt engineering is the practice of designing instructions that help an AI model produce better results.

Instead of just asking: Review this code.
You could be more specific: Review this implementation for potential bugs, security issues, and performance problems. Follow our team's coding standards, explain your findings, and prioritize them by severity.

The second prompt gives the model a clearer objective and expectations. But there's a limitation: a good prompt alone doesn't guarantee a good result.

If the model doesn't have access to the relevant code, documentation, or tools, there's only so much it can do.

And that's where Context Engineering comes in.

Context Engineering

This is one of my favorite concepts because it changes how we think about working with AI. While Prompt Engineering focuses on how we ask, Context Engineering focuses on what information the model has available when it needs to do the work.

Context engineering is the practice of selecting, organizing, and delivering the right information to a model at the right time.

And it's not just about adding more context.

Imagine asking an agent to investigate why an API request failed. You could dump thousands of lines of logs, the entire codebase, and all your documentation into the context window. But would that actually help?

Maybe. Or maybe the important information would get buried under a bunch of irrelevant data.

A better approach might be to provide the request ID, the relevant service architecture, and tools that allow the agent to retrieve specific logs or documentation as needed.

The goal isn't to give the agent all the information. It's to give it the right information.

This can involve retrieving documents, summarizing previous interactions, filtering tool results, managing conversation history, and deciding what should remain in the context window.

Harness Engineering

Remember the Agent Harness we talked about earlier? Harness Engineering is the practice of designing and improving that environment so agents can work more effectively, reliably, and safely.

If Context Engineering is about managing the information available to the model, Harness Engineering is about designing the system in which the agent operates.

For example, imagine you're building an agent that reviews pull requests. You might configure its harness to:

• Retrieve the PR description and changed files.
• Load the team's coding standards.
• Provide tools to inspect the repository and run tests.
• Restrict which commands the agent can execute.
• Require evidence for every issue it reports.
• Run automated checks to validate its findings.

Notice that we haven’t changed the underlying model. We’ve improved the environment around it.

And that's the interesting part: sometimes the biggest improvement doesn't come from a better model, but from a better setup.

Context Engineering and Harness Engineering overlap quite a bit, but they're not exactly the same thing.

Context Engineering focuses on the information the model receives, while Harness Engineering covers the broader execution environment, including tools, permissions, workflows, and feedback loops.

RAG (Retrieval-Augmented Generation)

Okay, another acronym, haha. RAG stands for Retrieval-Augmented Generation. It's a technique that allows an AI system to retrieve relevant information from external sources and use it when generating a response.

Instead of relying only on what the model learned during training, the system can look up information from documents, databases, knowledge bases, or other sources.

For example, imagine you have hundreds of internal technical specifications.

You ask: Does this implementation follow the authentication specification?

A RAG-based system could search those documents, retrieve the relevant sections, and provide them to the model so it can compare the implementation against the requirements.

A common approach uses embeddings and vector databases to find semantically similar content, but RAG isn't limited to vector search. Keyword search, hybrid search, and other retrieval methods can also be used.

RAG is one way of providing relevant context to a model without putting everything into the prompt upfront.

And while RAG can help ground responses in real information, the model can still misinterpret what it retrieves. The quality of the sources and retrieval process matters.

MCP (Model Context Protocol)

MCP is another term you'll hear everywhere when working with agents. And I think it's easy to misunderstand at first. MCP is a standard protocol that allows AI applications to connect to external systems that expose tools, resources, and prompts.

Think of it as a common interface between AI applications and external capabilities.

Without a shared protocol, each AI application might need a custom integration for every service it wants to use.

With MCP, a compatible client can communicate with MCP servers through a standardized protocol.

For example, you could have MCP servers that provide access to:

• GitHub repositories and pull requests.
• Jira tickets.
• Internal documentation.
• Observability platforms.
• Databases and other services.

An agent using an MCP-compatible application could discover available tools and call them to perform tasks, subject to the application's permissions and configuration.

But here's an important distinction: MCP isn't the tool itself. It's the protocol used to expose and access capabilities. And not every tool needs MCP. Agents can also use tools through native integrations, APIs, or other mechanisms.

Skills

Skills are one of the concepts I find particularly useful for everyday engineering work.

A skill is a reusable package of instructions, workflows, and sometimes supporting resources that helps an agent perform a specific kind of task.

Think about a task you perform regularly, like investigating an incident.

You probably have a process in your head:

• Identify the affected services and request.
• Retrieve the relevant logs.
• Check for related errors or recent deployments.
• Compare the behavior against the expected implementation.
• Summarize the findings with supporting evidence.

Instead of explaining that process to an agent every single time, you could define it as a skill.

Depending on the agent platform, skills might be stored as Markdown files with instructions, scripts, templates, or other resources that the agent can load when relevant.

And here's a distinction I think is worth remembering: Tools give agents capabilities. Skills teach agents how to use those capabilities to accomplish a task.

For example, a logging tool gives an agent the ability to search logs. An incident investigation skill tells it how to approach the investigation, which information to collect, what to verify, and how to report the results.

Skills don't necessarily provide new capabilities on their own, although some can include scripts or other executable resources. And when you combine skills with the right context and tools, you can start building agents that understand and follow your team's engineering workflows.

At this point, we have most of the building blocks. We have models that can reason about tasks, tools that let agents interact with external systems, context that provides relevant information, skills that guide how work should be done, and a harness that brings everything together.

But what happens when a task is too large or complex for a single agent? That's where subagents, scouts, and orchestration come into the picture.

4. What Counter-Strike Can Teach Us About AI Agents 🎮

Okay, actually nothing... Let's use Counter-Strike as an analogy. And if you've never played CS, don't worry, the idea is pretty simple. 😅

Imagine you're playing a match with a team of bots.

The Agent Is Your Player

Think of an AI agent as a bot playing Counter-Strike.

The bot has an objective, can make decisions, interact with the environment, and use the equipment available to it. But the bot doesn't magically know everything that's happening in the match. It needs information, capabilities, and a system that allows it to act.

Sound familiar? That's basically what we've been discussing about AI agents.

The Model Is the Brain, and the Harness Is the Game System

The LLM is like the decision-making engine behind your bot. It analyzes the available information and decides what to do next.

The harness is the software that connects those decisions to actions, similar to how the game system allows a bot to move, shoot, use equipment, and interact with the map.

And just like two bots with different decision-making capabilities might perform differently, different AI models can produce different results.

But even a great model won't be very useful if the environment around it doesn't provide the capabilities it needs.

Personas Are the Roles on Your Team

In Counter-Strike, players have different roles. You might have:

• IGL (In-Game Leader): Coordinates the team and calls strategies.
• Entry Fragger: Takes the first fights and creates space.
• AWPer: Focuses on holding angles and getting picks with the AWP.
• Support: Uses utility to help teammates.
• Lurker: Operates separately to gather information, control areas, or catch rotations.

These roles don't create new players. They describe how the players are expected to behave. It's the same idea with personas.

You can configure an agent to behave like a technical lead, an SRE, a code reviewer, or an orchestrator.

The agent is the player. The persona is the role assigned to that player.

And here's an important detail: giving a bot an AWPer persona doesn't automatically spawn another bot.

You still need an actual player configured and running.

Similarly, installing a persona doesn't necessarily create a new runnable AI agent.

Tools Are Your Weapons and Equipment

An AK-47, an AWP, a smoke grenade, or a flashbang gives a player different capabilities. But having an AWP doesn't automatically make someone a good sniper, right? haha

The same applies to AI agents.

Giving an agent access to a terminal, a logging platform, or a database doesn't automatically mean it knows how to use those tools effectively.

It still needs the right instructions, context, and decision-making capabilities. And tool calling is like the bot deciding when and how to use its equipment.

Context Is Your Game Information

Imagine playing Mirage without knowing where your teammates are, how much time is left, or whether the enemy team is stacking A or B.

Good luck with that.

In Counter-Strike, information comes from your radar, teammate callouts, sound cues, the economy, and what you've observed during the round.

That information helps you make better decisions. For AI agents, context plays a similar role.

An agent investigating a production issue needs relevant logs, request details, architecture documentation, and other information to understand what's happening.

And Context Engineering is like making sure your team receives the right callouts at the right time. You don't need every teammate shouting everything they see simultaneously. You need useful information that helps you make the next decision.

Skills Are Your Strategies and Playbooks

Think about a well-practiced A-site execute on Mirage.

Everyone knows the strategy: where to position, which smokes to throw, when to flash, and how to enter the bombsite. You don't need to explain the entire strategy from scratch every round.

That's similar to how skills work with AI agents. A skill provides reusable instructions and workflows for accomplishing a particular task.

For example, an incident investigation skill could define how to retrieve logs, correlate errors, inspect recent deployments, and report findings.

Tools give you the equipment. Skills give you the playbook for using it.

Subagents and Scouts Are Your Teammates

Now imagine you're the IGL.

You don't need to personally check every corner of the map. You can ask one teammate to watch mid, another to check B apartments, and another to prepare utility for an A execute.

In our analogy, those teammates represent subagents working on delegated tasks. And a scout is like the teammate you send to gather information before deciding what to do.

For example, you might ask a scout to check whether enemies are holding mid before committing to a strategy.

In AI Engineering, a scout might explore a codebase, locate relevant documentation, or investigate which services are involved in a request.

Remember: subagent describes the delegation relationship, while scout describes the specialization.

Orchestration Is Your IGL Calling the Round

Now let's imagine your IGL is an AI agent.

The objective is simple:

Win this round on Mirage.

The IGL might coordinate the team like this:

1. Ask the scout to gather information about mid.
2. Tell the support player to prepare smokes for A.
3. Ask the entry fragger to get ready.
4. Wait for the scout's callout.
5. Decide whether to execute A or rotate B.
6. Coordinate the team's actions based on what happens.

That's orchestration.

The IGL isn't necessarily doing every task. It's planning, delegating, collecting information, and adapting the strategy.

And this is exactly what an orchestrator agent can do in an engineering workflow.

For example, imagine asking an agent:

Investigate why our API is returning 500 errors.

It could delegate log analysis to one subagent, code inspection to another, and deployment investigation to a third. Then it collects their findings, compares the evidence, and produces a report.

The orchestrator is an agent performing a coordination role. Orchestration is the activity of coordinating the work.

And that's the distinction.

So, What's the Point?

The interesting thing is that you don't necessarily need a completely different AI model for each role.

Just like players on the same Counter-Strike team can have different responsibilities, agents using the same model can behave differently depending on their personas, tools, skills, and context.

And sometimes you don't even need multiple agents. A single well-configured agent might be enough for the task.

The goal isn't to build the biggest team of agents possible.

It's to give the right responsibilities, information, and capabilities to the right agents, and make sure their work is coordinated effectively.

And that's where Agentic Engineering starts to make a lot more sense.

5. Tools Worth Exploring

Okay, enough theory. What if you actually want to try some of this stuff?

There are plenty of tools out there for working with AI agents, and now that we've covered the concepts, I think it's easier to understand what these tools actually do.

Here are two interesting examples.

OMP (Oh My Pi) — An Agent Harness

Remember when we talked about Agent Harnesses?

Oh My Pi (OMP) is a practical example of one.

It provides an environment where AI models can interact with tools, execute commands, manage context, and work on engineering tasks.

And one of the interesting things is that you can configure specialized agents with different models, personas, tools, and permissions.

For example, you could have an orchestrator agent responsible for planning and delegating tasks, while other agents focus on implementation, investigation, or code review.

The important part is that OMP provides the environment where those agents can actually operate.

Herd — Multi-Agent Orchestration

Now, remember when we talked about subagents, scouts, and orchestration?

Herd is an example worth exploring when looking at multi-agent workflows. (Check the project’s current documentation and availability before adopting it.)

The idea is to coordinate multiple specialized agents working toward a common goal, rather than relying on a single agent to handle everything.

Think about our Counter-Strike analogy: instead of one player trying to do everything, you have an IGL coordinating teammates with different responsibilities.

That's the kind of problem multi-agent orchestration aims to solve.

And the interesting part is that orchestration isn't about having more agents just for the sake of it. It's about organizing the work so each agent can focus on what it does best.

Which One Should You Use?

I wouldn't focus too much on choosing the perfect tool right away.

The important thing is understanding the concepts behind them.

Once you understand models, harnesses, personas, tools, skills, and orchestration, it becomes much easier to explore different setups and understand what each one brings to the table.

And remember: you don't need a whole army of agents to practice Agentic Engineering.

Sometimes, a single well-configured agent with the right context and tools is exactly what you need.

---

6. Where to Start

If all of this sounds interesting but a little overwhelming, start small. You don't need a multi-agent system on day one.

Pick a task you already do regularly—investigating a failed request, reviewing a pull request, or checking an implementation against a technical specification. Give one agent a clear objective, access to only the tools it needs, and a simple checklist of what a good result looks like.

Then review what it produces. Did it find useful evidence? Did it make assumptions? Could you reproduce its conclusions? Improve the instructions, context, and permissions based on what you learn.

Only introduce subagents or orchestration when there's a real reason to split the work. More agents can also mean more cost, coordination overhead, and opportunities for mistakes.

For me, that's the most exciting part of Agentic Engineering. We're not just learning how to ask AI to write code. We're learning how to design better engineering workflows around it.

The goal isn't to automate judgment away. It's to give engineers better tools to investigate, build, and verify software.

I'm still exploring these ideas myself, so I'd love to hear how you're using agents in your day-to-day engineering work.