title: Building an optimized agent workforce slug: agent-workforce audience: end-user category: agents

Building an optimized agent workforce

Delegation and optimization are two features. The real power comes from combining them: build one saved agent per workflow, optimize each of them, and then use a small number of overseer agents to call those specialists. You end up with an army of cheap, fast, optimized specialists run by a few "manager" agents — and the whole system stays light on AI credits.

This page is a recipe for getting there.

The mental model

Think of it like an organization, not a single brain:

• Field agents — saved agents that each do one concrete job. "Create sales order", "Reconcile a customer balance", "Open a support ticket from an email", "Send the weekly stock report". Narrow scope, clear instructions, named entities.
• Overseer agents (sometimes called meta-agents or manager agents) — saved agents whose job is to decide which field agent to call, hand it the right input, and assemble the results. They don't query ERP, don't write emails, don't touch documents themselves. They delegate.

Field agents do the work. Overseers do the routing.

Why this combination wins

Each piece pulls its weight:

• One agent per workflow keeps instructions short and unambiguous. Short instructions = cheaper turns and fewer mistakes.
• Optimization pre-resolves the names, IDs, and reference data each field agent needs. The first turn of every call skips the warm-up and goes straight to the work. (See Agent optimization.)
• Delegation lets one agent call another as a sub-task. The overseer never has to know how to actually create a sales order — it just calls the agent that does. (See Delegation & Sub-Agents.)
• Overseers stay cheap. They reason at a high level, hand work down, and read short results back. They don't touch ERP, so they don't trigger discovery, don't load schemas, don't burn credits looking things up.
• Field agents get called many times. That's exactly when optimization pays off — the 15–20 credits you spent optimizing each one are recouped after a handful of calls.

The result: most of the heavy lifting happens inside optimized agents, the orchestration on top is light, and the total cost per business outcome drops significantly.

A worked example

Say you run weekly sales operations on one ERP instance. You might end up with:

Field agents (each optimized for the instance):

• Order Creator — takes a customer + line items, creates the sales order with the right document type, store, currency, and price list.
• Order Statuser — looks up an order by number and reports its current state, deliveries, and outstanding balance.
• Customer Onboarder — creates a new customer with the correct group, tax setup, and payment terms.
• Stock Reporter — pulls warehouse stock for a list of products and returns a compact summary.

Overseer agent (NOT optimized — it doesn't touch ERP):

• Sales Ops Manager — its only job is to read your request ("onboard this customer and place their first order"), decide that this means Customer Onboarder then Order Creator, call them in turn, and report back. Its instructions list the field agents it's allowed to call and when.

You talk to Sales Ops Manager. It does the routing. The field agents do the work — fast, because each one already knows your document types, stores, and price-list IDs from optimization.

How to build it, step by step

1. List your real workflows. Be concrete. Not "handle sales" — but "create a sales order", "check an order's status", "onboard a new customer". One workflow = one future field agent.
2. Build each field agent. Write tight instructions naming the specific ERP things it works with (document types, stores, price lists, contexts…). Test it standalone until it reliably does its one job.
3. Optimize each field agent for the instance(s) it will run on. Open the agent → Optimization tab → Optimize. See Agent optimization for details.
4. Share the field agents with the users (or the overseer's owner) who'll need them. See Sharing Agents. An overseer can only delegate to agents it has access to.
5. Build the overseer. Keep its instructions focused on routing:
   • what it's responsible for at a high level,
   • the list of field agents it's allowed to call, with one line each about when to use them,
   • how to combine their outputs into a final answer. Do not give the overseer broad ERP capabilities — keep it light. The point is that it delegates.
6. Turn on delegation on the overseer (the sub-agents capability). Without it, the overseer has no way to call the others.
7. Don't optimize the overseer. It doesn't need ERP discovery — it doesn't talk to ERP. Optimization on an overseer is wasted credits.
8. Use the overseer as your single entry point for that area of work. Add it to your suggested actions or pin it.

When not to do this

• One-off or exploratory work. If you're just poking around, a single general agent is fine. The army is for repeatable workflows.
• A workflow that's still changing every day. Stabilize the field agent's instructions first, then optimize. Re-optimizing after every small tweak is wasteful — see the re-run guidance in Agent optimization.
• A workflow with only one step. No overseer needed — just call the field agent directly.

Cost intuition

A rough way to think about credits:

• Optimizing a field agent: ~15–20 credits, one-time per instance (re-run only when instructions or named entities change substantially).
• Calling an optimized field agent: cheaper per call than an unoptimized one, because the first turn skips discovery and schema loading.
• An overseer turn: cheap, because it's reading short instructions and short sub-agent results — no schemas, no ERP roundtrips.
• A full overseer-driven run: a few cheap overseer turns + a few cheap optimized-field-agent runs. Compare that to one big do-everything agent re-discovering the same entities on every conversation, and the savings compound the more you use the workflow.

A few practical tips

• Name field agents by their job, not their domain. "Create Sales Order" beats "Sales Bot" — both for you and for the overseer's instructions.
• Keep each field agent's scope honest. If it starts needing to "also sometimes do X", consider splitting X into its own agent rather than widening this one. Narrow agents stay optimizable.
• Give the overseer an explicit allow-list of field agents in its instructions. Don't make it guess.
• Re-optimize field agents after meaningful instruction changes or after you've added several new named items they refer to. A stale optimization doesn't break anything — the agent just falls back to live lookups — so don't re-run after every tiny edit.
• Watch the first few real runs. If the overseer is hesitating about which field agent to call, tighten its routing instructions; if a field agent is doing extra discovery on every call, its optimization is probably stale or missing an entity — re-run it.

That's the whole pattern: small, sharp, optimized specialists doing the work; a couple of light overseers doing the thinking. Build it once, and your day-to-day operations get faster and cheaper every week.