Agentic Engineering: Picking the Right Agent for the Right Job

Most AI projects that stall do not fail because the model is weak. They fail because the team built a five-agent system for a job that needed one well-prompted call, or they handed a single agent fifteen tools and a vague goal and hoped for the best. Agentic engineering is the discipline of matching the shape of the system to the shape of the work, and it starts with an unglamorous question: what does this task actually need?

What agentic engineering actually means

An agent is a loop. A model reads some context, decides on an action (usually a tool call), sees the result, and decides again until it reaches a stopping condition. That is the whole idea. Everything else, from planners to sub-agents to memory, is an elaboration of that loop.

Agentic engineering is the work around the loop: deciding how much autonomy the model gets, which tools it can touch, which model runs each step, where a person signs off, and how you know when it has gone wrong. It looks a lot more like systems design than prompt writing. The prompt matters, but the boundaries matter more.

A useful way to frame it is a ladder of autonomy:

1. Single call. One prompt, one answer, no loop. Classification, extraction, summarization, drafting.
2. Fixed workflow. Several model calls chained in code you wrote. The model fills in steps, but your code decides the order.
3. Single agent. One model in a loop with a set of tools, choosing its own next step.
4. Multi-agent. Several agents with separate contexts, coordinated by an orchestrator or by handoffs.

Each rung up buys flexibility and costs you predictability, latency, money and debuggability. The right answer is the lowest rung that reliably does the job.

When an agent is overkill

Teams reach for agents because they are exciting, not because the task demands one. Before you build a loop, check whether the work has any real decisions in it. If you can draw the flowchart on a whiteboard and it does not change from one request to the next, you want a workflow, not an agent.

Signs that an agent is overkill:

• The steps are always the same and always in the same order.
• There is only one tool, or the tool to call is obvious from the input.
• The output is a single artifact (a summary, a label, a JSON record) with no follow-up actions.
• A wrong step is expensive or irreversible, and nobody will review it.
• You need a response in under a second or two.

Take a support inbox triage feature. You need to classify each message, pull out the order number, and route it. That is one structured-output call and a lookup. Wrapping it in an agent adds a loop that can wander, retry, or call tools it did not need, and it makes every failure harder to reproduce. A plain function with a schema is faster, cheaper and easier to test.

Agents earn their keep when the path genuinely depends on what the model discovers along the way: researching across sources, debugging, multi-step booking with exceptions, or reconciling records where each mismatch needs a different fix.

Single agent or multi-agent?

Once you know you need a loop, the next temptation is to split the work across many specialized agents. Sometimes that is right. More often, one agent with good tools and a clear prompt beats a committee.

Start with one agent

A single agent keeps all context in one place. It does not lose information in handoffs, it is easier to trace, and there is only one prompt to tune. Most production assistants we see, including support bots and internal ops agents, work best as one agent with a focused toolset and a few guardrails.

Split when you hit a real limit

Move to multiple agents when one of these is true:

• Context pressure. The task needs more material than fits comfortably in one context window, and the pieces can be worked on independently (for example, reviewing 40 contracts in parallel and merging findings).
• Different permissions. One part of the job should be able to read customer data and another part should never see it. Separate agents with separate tool access make that boundary enforceable.
• Different models. A cheap, fast model can handle routing and extraction while a stronger model handles the hard reasoning.
• Parallelism. Independent subtasks can run at the same time and cut wall-clock time.

The common pattern is an orchestrator that plans and delegates, plus workers that each get a narrow brief and return a compact result. Keep the contract between them explicit: what the worker receives, what it must return, and in what format. Vague handoffs are where multi-agent systems quietly fall apart.

Picking the right model for each step

"Right agent for the right job" applies to models too. There is no reason the step that decides which department a ticket belongs to should run on the same model as the step that drafts a careful reply to an angry enterprise customer.

Do not pick by benchmark headlines. Build a small evaluation set from your own data, 50 to 200 real examples with known good answers, and run each candidate model against it. You will often find a cheaper model matches the expensive one on your task, and you will occasionally find the opposite. Re-run that set whenever you change a model or a prompt.

Also design for swapping. Put model calls behind a thin interface so changing providers or tiers is a config change, not a rewrite. Prices and capabilities move every few months.

Tool design is where agents succeed or fail

An agent is only as good as the tools you give it. Models are surprisingly good at deciding what to do and surprisingly bad at guessing what a badly named tool does. Treat tools as an API designed for a new hire who reads every word literally.

• Fewer, clearer tools. Ten overlapping tools confuse the model. Merge or remove until each tool has one obvious purpose.
• Descriptive names and docs. search_orders_by_customer_email beats query. Say what the tool returns and when not to use it.
• Tight input schemas. Use enums, formats and required fields so bad calls fail fast with a helpful error.
• Compact outputs. Return the five fields the agent needs, not a 300-line JSON blob that eats the context window.
• Least privilege. Read-only by default. Write and delete actions get separate tools with their own checks.

Here is an example of a tool definition that gives the model what it needs to use it correctly:

{
  "name": "reschedule_appointment",
  "description": "Move an existing appointment to a new slot. Only use after confirming the new time with the customer. Returns the updated appointment or an error if the slot is taken.",
  "input_schema": {
    "type": "object",
    "properties": {
      "appointment_id": { "type": "string", "pattern": "^apt_[a-z0-9]{12}$" },
      "new_start": { "type": "string", "format": "date-time" },
      "reason": { "type": "string", "enum": ["customer_request", "clinic_request", "no_show"] }
    },
    "required": ["appointment_id", "new_start", "reason"]
  }
}

If you are exposing tools across several products or assistants, the Model Context Protocol (MCP) gives you a standard way to do it, and most major clients now support it. It does not solve permissions, audit trails or rate limiting for you, so plan those yourself. Our team covers this kind of plumbing as part of AI integration services.

Where humans stay in the loop

Human-in-the-loop is not a sign that the agent is weak. It is how you ship something useful before you trust it with everything. The trick is putting the checkpoint where the risk is, not everywhere.

A practical rule: let the agent act freely on anything that is reversible and low cost, and require approval for anything that moves money, contacts a customer, changes records others depend on, or cannot be undone. A booking agent can search slots and draft a confirmation on its own. Cancelling a paid appointment or issuing a refund waits for a person, at least until you have weeks of logs showing it gets those right.

Make approvals cheap. Show the reviewer the proposed action, the reason, and the evidence the agent used, with one-click approve or edit. If approval takes longer than doing the task by hand, people will rubber-stamp it, and you will have the risk without the safeguard.

Finally, give every agent a budget: a maximum number of steps, a token ceiling, and a timeout. When it hits a limit, it should stop and hand off to a person with a summary of what it tried, not loop until the bill arrives.

A simple decision checklist

Before committing to an architecture, run through these questions with your team:

1. Can a single structured call do this? If yes, stop there.
2. Is the sequence of steps fixed? If yes, build a workflow in code.
3. Does the path depend on what is discovered mid-task? Then use one agent with focused tools.
4. Do you need separate permissions, separate models, or parallel work? Only then split into multiple agents.
5. Which actions are irreversible? Put a human checkpoint on exactly those.
6. How will you measure it? Build the evaluation set before you build the agent.

Teams that follow this order tend to ship faster and spend less, because they add complexity only when the work forces them to. If you want a deeper look at building the agent layer itself, our agentic AI development work follows the same progression.

How Softzee can help

We design and build agents for real workloads, from Arabic and English voice agents that book appointments to support assistants on web and WhatsApp, and we are just as happy to tell you when a simple workflow will do. If you are weighing an agent for a specific process, book a call and we will walk through it with you.