The Agent That Plans: How Alhena Decides What to Do Before It Answers

Most e-commerce chatbots follow a simple loop: receive a message and generate a response. Alhena does something different.

Before it writes a single word, a dedicated component called the Planner decides which specialized agents should handle the request, in what order, and for which part of the message. Then, as those agents execute, a second component called the Replanner continuously checks whether the plan still makes sense and adjusts mid-conversation.

It's the difference between a junior rep who blurts out an answer and a senior rep who pauses, scopes the problem, assigns the right specialists, and adapts when something unexpected comes up. The goal is simple: give every customer the right answer from the right specialist, every time. This post explains how Alhena's planner agent works, why it matters for e-commerce, and what makes it different from typical agentic AI approaches.

Two earlier posts cover why we moved from RAG to planning and how our multi-agent system is structured. This post goes one level deeper: into the planner’s decision logic itself.

Why a Planner Agent Exists in Agentic AI

Alhena isn't one monolithic model. It's a team of specialized agents: ProductExpert, OrderManagement, ReturnManagement, SizingAssistant, LeadGeneration, HumanTransfer, and others. Each agent has its own tools, knowledge, and guidelines.

The problem: when a customer says, "I want to return my jacket and also check on my other order," that's two jobs for two different agents. Someone has to decompose the request, route each piece to the right specialist, and combine the results. That someone is the planner agent.

Without a planner, agentic AI systems default to one of two bad options. Most e-commerce systems in 2026 still rely on one or the other. Either a single agent tries to handle everything (and drifts off-topic), or a rigid workflow forces every conversation through the same static path. Alhena's planning architecture sits between these extremes: structured routing with the flexibility to adapt when reality doesn't match the initial plan.

Phase 1: PLAN, Deciding What to Do

When a message arrives, the planner agent runs first. It receives four inputs:

• Agent Cards: structured descriptions of every agent available in that brand's configuration, including skills, tools, and MCP servers
• Knowledge Summary: a high-level map of the brand's knowledge base (enough to route, not enough to answer)
• Handoff Guidelines: business rules like "send warranty questions to WarrantyAgent when the purchase is under a year old"
• User Context and Memory: location, order history, prior interactions

From these inputs, the planner produces a structured JSON plan containing an ordered list of agent tasks. Each task specifies which agent should run and includes an exact sub-query quoted from the customer's message. For the jacket-and-order example, the plan looks like this: ReturnManagementAgent handles "I need to return my jacket," then OrderManagementAgent handles "Check my order status."

A few design choices worth noting. The planner agent never talks to the user directly. It only produces the plan, keeping routing decisions clean and auditable.

Sub-queries are quoted from the original message, never paraphrased. This prevents the planner from rewriting the customer’s intent. Knowledge retrieval runs in parallel with planning, so while the planner routes, the retriever is already fetching detailed context each agent will need. No wasted time.

As teams learn how their agent plans perform in production, they can refine execution patterns without changing code.

Phase 2: REVIEW, Adapting as Things Unfold

This is where Alhena's agentic AI system gets genuinely interesting. After each agent finishes, the planner is invoked again in REVIEW mode. It looks at the agent's output and picks one of three actions:

• CONTINUE: the agent did its job. Proceed to the next task.
• REPLAN: something changed. Tear up the remaining plan and write a new one.
• COMPLETE: the user's request is fully handled. Stop executing.

Replanning triggers when the agent uncovers new information that changes the scope. A "check my order" query might reveal the order was never placed, which means the conversation needs a LeadGeneration agent instead. If an agent escalates to human support, HumanTransferAgent gets injected into the plan. If a prompt injection attempt is detected, the system reroutes to RefusalAgent.

Just as important is when the replanner doesn’t fire. It never replans to "correct" an agent’s answer. Replanning is strictly about routing: which different agent should run next.

An agent politely offering "would you like to speak to a human?" isn’t the same as escalating, so that doesn’t trigger a replan either. This distinction keeps the multi-agent system predictable and debuggable.

Safety Built into the Loop

Agentic AI systems need guardrails at the architecture level, not bolted on as afterthoughts. Alhena's planner agent includes several structural safeguards.

Replanning is capped at three attempts per conversation. If the cap is hit, the system hands off to RefusalAgent, which produces a clear, safe response rather than spinning in a loop. For simple cases where the plan has a single terminal agent like GreetingAgent, replanning is skipped entirely.

The planner can only pick from agents that are explicitly configured for that brand. If it tries to reference a non-existent agent, the orchestrator silently replaces that task with RefusalAgent. The system never breaks, and the failure is visible in the plan trace for debugging.

Invalid routing, prompt injection, infinite loops: each failure mode degrades gracefully instead of catastrophically. Brands like Tatcha and Puffy run this system at scale with 90%+ CSAT because safety is structural, not optional.

The Full Execution Lifecycle

Here's what happens from the moment a customer hits send:

1. The planner agent runs in PLAN mode and produces an initial plan
2. The plan is validated (any invalid agent references get replaced with RefusalAgent)
3. Knowledge retrieval, running in parallel, finishes producing agent-specific context
4. Agent #1 executes with its scoped sub-query and detailed knowledge
5. The replanner evaluates the output: CONTINUE, REPLAN, or COMPLETE
6. The execution cycle repeats until COMPLETE or the safety cap triggers a graceful refusal

This lifecycle means Alhena handles multi-intent messages natively. "Do X and also Y" conversations don't need hacks or workarounds because plans are ordered lists of sub-queries by design. When Manawa dropped response times from 40 minutes to under one minute, this planning architecture was a core reason: the system routes to the right specialist on the first pass instead of bouncing the customer around.

Why This Matters for Ecommerce

The planner agent is what lets Alhena act as a team of specialists rather than a single generalist. Three qualities make this approach stand out for enterprise ecommerce systems.

Configurability without chaos. Every brand ships with its own agent roster, guidelines, and knowledge. The planner respects that boundary. It can only pick from what’s been configured, never from its imagination.

Adding a new agent is as simple as registering its skill card. The planner automatically starts routing relevant queries to it.

Two-tier knowledge. The planner routes on a summary of the knowledge base. Individual agents consume the detailed product data, policies, and FAQs.

Routing decisions stay fast. Answers stay grounded.

This separation is why Alhena delivers hallucination-free responses at scale.

Auditability. Every plan, every replan decision, every agent task is logged. CX teams can open the Conversation Debugger, see exactly why the planner routed a conversation the way it did, and adjust guidelines without filing an engineering ticket or consuming engineering resources. For a deeper look at the technical blueprint behind this architecture, see our engineering guide.

The Right Analogy

Think of Alhena like a well-run support team. A dispatcher (the planner) reads the incoming request, splits it into work items, and assigns each to the right specialist.

As each specialist reports back, a supervisor (the replanner) checks whether the ticket is on track, reroutes to a different team if needed, and closes the ticket only when the shopper’s problem is actually solved. No single agent has to know everything. The system as a whole is what’s smart.

Ready to see how planning-first AI handles your customers' questions? Book a demo with Alhena AI or start free with 25 conversations.

Alhena AI

Schedule a Demo

Frequently Asked Questions