Agent Builder
Shape AI around how your operation actually works.
Build around your own process.
01
Define the job
Describe the role, the goal and the rules in plain language — one job, the outcome it should produce and what it must never do.
02
Give it context
Choose the knowledge, records and history it may use: which records, which journey stages and events it responds to, and approved knowledge only.
03
Set boundaries
Pick the tools it may use, the policies it follows and what needs a person: guardrails, scope, working hours, an escalation owner, and whether it drafts or acts.
04
Test, approve, put to work
Try it on real examples in a test console. An admin approves the version before it goes live — then it’s hired like any other agent.
Inside the builder
Every part of an agent, on one canvas.
Illustration
Intake follow-up
An illustrative custom agent, not a product. Everything around it is a part you set.
01
Trigger
Which records, journey stages and events it responds to.
Form submitted · New lead stage
02
Instructions
The system prompt: the job, the tone, the rules and when to escalate — in plain language, versioned with the agent.
System prompt · version 3
03
Knowledge
Knowledge bases built from approved sources, with ingestion status. It answers from what it was given.
Intake FAQ · indexed
04
Tools & MCP
Named, executable actions — read a contact, create a task, move a stage. Other MCP servers can be added, each with its own secrets.
Read a contact · Create a task
05
Guardrails
Runtime rules, such as personal-data handling and forbidden topics, checked on every response.
No prices or promises
06
Structured output
Free text or structured fields — so an intake agent returns a record, not a paragraph.
Fields → contact record
07
Approval
When setup is complete, the version is submitted. An admin or reviewer approves it before it can be hired.
Version 3 · awaiting reviewer
Illustration of the Agent Builder canvas.
Two ways to work with AI
Using agents versus creating them.
Using agents
A ready-made agent arrives with its job defined: Borrower Engagement answers leads, Document Intelligence chases documents. You decide scope and authority at hire. You never see a prompt.
Creating agents
A custom agent starts from your process: the job in plain language, the knowledge it may use, the tools it may call and the boundaries it must respect. It’s tested, submitted, approved and versioned — then hired like any other agent.
Roles
Who builds, who approves, who uses.
Builders
Who builds
Workspace admins and people given the builder role.
Reviewers
Who approves
An authorised reviewer — typically an admin or a compliance officer — approves the version, then the hire. Both steps are recorded in the audit log.
Everyone else
Who uses
Team members see the agent’s work on records and in agent chat. They never see prompts, models or servers — and they don’t need to.
FAQ
Questions about building agents.
Who builds our first agents?
Muvix builds and configures your first custom agents with your team, using the builder described on this page. Your own builders then work through the same lifecycle.
Which models can an agent use?
The builder is designed to work with several model providers, chosen per agent. We’ll go through the options for your workspace with you.
Does a custom agent follow the same rules as a ready-made one?
Yes. Same hire approval, same scope, same review before customer messages are sent, same audit log.
What happens when we edit a live agent?
Editing creates a new draft. The hired version keeps running until the new version is tested, submitted and approved.
Keep going
Under the same rules as the rest of Muvix.
Governance & control
A custom agent works under the same roles, reviews and audit log as your team. Customer messages wait for a person unless an admin decides otherwise.
AI agents
The ready-made agents — Borrower Engagement and Document Intelligence — and how any agent is approved for your workspace.
Integrations, tools & MCP
The tools and knowledge a custom agent can be given, and the systems they connect to.