AI agents

A Nexus agent is a small team of specialised agents working together, with their behaviour shaped by a shared Configuration, running on the Nexus engine. The engine adds platform-enforced refinements (two-stage routing, automatic step execution, parent-child agent triggers with auto-return, history compaction, structured traces) and authoring surfaces like Routing Logic, Widget Builder, the AI Trust Centre, and versioned configuration. See What the Nexus engine does for you for the full list.

The building blocks

Specialised agents now come in two types:

• Single agents - LLM-driven specialists that work out each reply on their own from your instructions and knowledge. Best for open-ended Q&A, troubleshooting, and anything where the path depends on what the user says.
• Multi agents - deterministic agents that run the exact steps you lay out on a flow canvas, in the same order every time. Best for fixed procedures that must run consistently and auditably - order returns, KYC checks, booking flows. See Multi agents.

Configuration

Configuration is project-level - the settings you define here apply to all your agents, single and multi agents alike. It's where you set persona, identity, conversation rules, routing logic, memory, fallback, lifecycle hooks, and AI safety. (Voice settings is also project-level but lives on its own surface, AI Agent → Voice.) At runtime:

• Every incoming message is read.
• Routing decides whether to answer directly or hand off to one of your agents.
• Your persona, identity, and rules shape the reply.
• Tools (workflows, knowledge base lookups, escalations) are called when data is needed or an action must be taken.

You set this up in AI Agent → Configuration. See Configuration for the full tour.

Agents

Agents are specialists you design for one job each - an order-status agent that answers "Where's my order?", a demo-booking agent that helps users pick a slot, a billing agent that handles refunds and invoices. Every agent inherits the project-level Configuration above; on top of that, agents come in two types:

• Single agents - LLM-driven specialists that work out each reply on their own. (guide)
• Multi agents - deterministic agents that run a fixed flow you lay out on a canvas. (guide)

You create either type from the same Create picker - start at Create an agent. Each agent can also follow its own rules in addition to the shared Configuration's, though you'll rarely need that on day one.

Routing decides when to hand off to an agent. It reads each agent's Trigger (the natural-language description at the top of the agent's profile) as the primary routing signal. You can optionally add Routing Logic rules to make specific handoffs deterministic when Triggers alone aren't precise enough. Once an agent takes over, it owns the conversation until control returns.

You manage agents in AI Agent → Agents.

Global components

These are reusable pieces - shared prompts, policy text, tone snippets - that you can pull into any agent. Define them once, reuse them everywhere. Update them in one place and every agent using them gets the change.

You manage these in AI Agent → Global Components.

Tools

Tools are the actions an agent can take in the real world: call a workflow, search a knowledge base, escalate to a human, transfer a call. You define them once and any agent in the bot can use them - and they can be called directly at the Configuration level too. Attach a tool to a specific agent when it belongs to that agent's job; that also helps route a topic to the right place.

How routing decides what to do

When a user sends a message, one of three things happens: it's answered directly, it's handed off to an agent (a single agent, or a multi agent enabled as a delegation target), or a tool is called. The primary signal is each agent's Trigger - for simple bots with clearly distinct Triggers, that's all you need. Add optional Routing Logic rules on top only when Triggers alone aren't precise enough to disambiguate.

See Routing Logic for the full mechanics - how Triggers and rules interact, how tools fit in, and how to write rules that are actually testable.

Where to find each surface in the studio

Want to…	Go to
Edit Configuration (project-level - applies to all your agents)	AI Agent → Configuration
Add or edit agents	AI Agent → Agents
Manage shared snippets	AI Agent → Global Components
Build a custom widget	AI Agent → Widget Builder
Test your agent	AI Trust Centre (top-level menu item)

A typical build flow

If you're starting fresh, work in this order:

1. Set up Configuration - project-level persona, identity, welcome, fallback that apply to every agent. (guide)
2. Create an agent for each distinct task (order status, demo booking, billing) - single or multi agent. (guide)
3. Write Routing Logic rules when you want a topic to always route to a specific agent. (guide)
4. Add tools to whichever agents need them.
5. Test interactively in the Playground (▶ on each agent), then regression-test with datasets in the AI Trust Centre. (guide)
6. Build widgets if you need custom UI. (guide)
7. Deploy - connect your agent to channels (web, WhatsApp, voice, …) and publish it. (Channels & Deploy)
8. Monitor - track conversations, performance, and quality once it's live. (Analytics)

Steps 1-6 live in Harness; deploy and monitor are handled by the sibling Channels & Deploy and Analytics products - the build → test → deploy → monitor lifecycle spans the product rail, not just this section.

What the Nexus engine does for you

On top of the specialised-agents + shared-Configuration + tools model above, the Nexus engine adds a set of platform-enforced behaviours - two-stage routing, automatic step execution, parent-child agent triggers, history compaction, structured execution traces, and more - plus authoring surfaces like Routing Logic, Widget Builder, the AI Trust Centre, and versioned configuration.

See What the Nexus engine does for you for the full area-by-area breakdown.

Best practices

• Start small. Just your Configuration with no extra agents is a perfectly good starting point. Add agents only when you have clearly separable tasks.
• Name agents by the task they own. order-status-agent, demo-booking-agent, billing-agent beat agent2. Sharp names lead to sharp routing.
• Don't build a "general" agent. A general-purpose agent is a sign routing isn't doing its job. Keep each agent focused on one task.
• Write rules in plain English, then test. It's easier to refine wording after seeing how routing interprets it than to engineer a perfect rule upfront.
• Use Global Components for anything you copy more than once. Policy text, brand voice instructions, common disclaimers - define once, reuse.
• Test before every release. Even small wording changes to identity or rules can shift behavior. Regression-test with a saved dataset before you ship.

Continue to: Configuration.