What is an AI agent builder? How they work, the types, and how to choose

A customer emails at 2am: they were charged twice for their annual plan. By the time the support team logs on, an agent has read the ticket, found the account in the CRM, confirmed the duplicate charge in billing, drafted a refund, and posted it in Slack for a finance manager to approve. One click later the refund is issued, the customer has a reply, and the ticket is closed with a note on what happened. Four systems, one human decision, no copy and paste.

The software used to make that agent is an AI agent builder.

The short answer. An AI agent builder is software for creating AI agents: programs that read a request, decide which steps to take, and use tools to act in other systems. You give an agent a model, instructions, knowledge, and tools, and choose where people reach it. Enterprise builders also control what each tool can do, ask a person to approve sensitive actions, and record every call. The best one for you depends on where your agents need to act.

This guide covers what a builder does, how an agent works step by step, the four types of builder, and how agents relate to workflows, chatbots, and MCP. If you already know what you want and need a shortlist, see the 10 best AI agent builders for enterprise. If you are writing a buying checklist, see how to choose a no-code AI agent builder.

What is an AI agent builder?

An AI agent is software that takes a goal, works out the steps, and acts. An agent builder is where you assemble one. Almost every builder, whether it is a no-code canvas or a Python library, asks you to define the same parts:

• A model. The large language model that reads the request and decides what to do next. Most builders let you choose between providers, and some let you bring your own.
• Instructions. The agent’s job description, written in plain language: what it is for, what it must never do, and when to hand off to a person.
• Tools. The actions the agent can take in other systems, such as “look up account”, “create ticket”, or “issue refund”. Tools are what separate an agent from a chatbot.
• Knowledge. Documents, policies, and records the agent can search for context, kept fresh as the source changes.
• Memory. What the agent remembers within a conversation, and sometimes across conversations.
• Channels. Where people talk to the agent or where it is triggered: Slack, Microsoft Teams, a website chat, an email inbox, or an API call from another system.
• Guardrails. Limits on what the agent can say and do, including human approval before sensitive actions and protection for personal data.
• Evaluation. Test cases that check the agent behaves correctly before release and after every change.
• Monitoring. A record of every decision and tool call, so you can see what the agent did, why, and what it cost.

A builder that only covers the first four is enough for a demo. The last five decide whether the agent can be trusted with real work.

How an AI agent works, step by step

Take the duplicate-charge ticket from the top of this page. Here is what the agent does, and what the builder had to provide for each step.

1. A trigger arrives. A new ticket lands in the support tool. The builder’s channel setup routes it to the agent.
2. The agent reads and plans. The model reads the ticket and its instructions, and decides it needs the customer’s account, their recent charges, and the refund policy.
3. It looks things up. It calls a “find account” tool against the CRM and a “list charges” tool against billing. Both tools are read-only, scoped to exactly those operations.
4. It checks policy. It searches the knowledge base and finds that duplicate charges are refunded in full, and that any refund over a set amount needs a finance manager’s approval.
5. It proposes an action. It drafts the refund and posts a summary in Slack: the customer, the two charges, the policy it applied, and an Approve button.
6. A person decides. The finance manager approves. Had they declined, the agent would have added a note to the ticket and handed it to a person.
7. It acts. The agent calls the “issue refund” tool. That tool is a workflow, not a free-form API call, so it validates the amount, writes to billing, and logs the result the same way every time.
8. It closes the loop. It replies to the customer, updates the CRM record, and closes the ticket with a summary.
9. Everything is recorded. Every tool call is logged with the model’s reasoning, the credentials used, the approver, and the outcome.

The model did the reading and deciding. Everything else, the connections, the scoped tools, the approval, the reliable refund workflow, and the log, came from the builder and the platform underneath it. That is why the choice of builder matters more than the choice of model.

AI agent vs chatbot vs copilot vs workflow automation

These terms get used loosely, and many products now combine them. The useful question is what the software can change in your systems.

	What it does	Who decides the steps	Example
Chatbot	Answers questions in a conversation	Script or model, but it only replies	”What is your refund policy?”
Copilot	Suggests text or actions inside an app for a person to accept	The person	Drafting a reply in the support tool
Workflow automation	Runs steps you defined in advance	You, at design time	”When a ticket is tagged billing, assign it to finance”
AI agent	Works toward a goal and calls tools to act	The agent, within its limits	Resolving the duplicate-charge ticket end to end

Our guide to the difference between chatbots, copilots, and AI agents goes further on the first three.

Why most production agents use workflows too

Agents and workflows are not rivals. An agent is good at judgment: reading an untidy request, working out what is wrong, choosing what to do. A workflow is good at doing the same thing correctly every time: issuing a refund, provisioning a licence, updating five fields in the right order.

So the pattern that holds up in production is an agent that decides, calling workflows that execute. The refund in the example above is a workflow exposed to the agent as a tool. The agent chooses when to refund, and the workflow controls how. That keeps the parts that must never vary out of the model’s hands, and it means the same refund logic serves the agent, the support team, and any other process that needs it.

This is also why an agent builder sitting on an integration platform has an advantage for cross-system work: the workflows and connections already exist, and the agent uses them.

Types of AI agent builder

There are four broad places to build an agent. Each is the right answer for some teams.

No-code builders on an integration platform

These start from connections. The platform already connects to your CRM, ERP, ticketing tool, and data warehouse, stores the credentials, and runs workflows, and the agent builder sits on top. You define the agent visually or in plain language, and its tools are the platform’s connectors and workflows. They suit agents whose work crosses many vendors’ systems, built by IT, operations, or business teams, often with developers adding code steps. Tray.ai, Workato, Zapier and n8n all build agents this way, with different trade-offs; the comparison covers each.

Builders inside a suite you already own

The large application suites have their own builders. Microsoft describes Copilot Studio as “a graphical, low-code studio for building and managing AI-powered agents and workflows”, where you can create an agent by describing it in plain language and publish it to Teams, Microsoft Copilot, websites and mobile apps.¹ Copilot Studio agents can also use tools from MCP servers.² Salesforce describes Agentforce Builder as “a low-code AI agent builder” where you build agents “in plain language on Canvas”, connected to “existing Salesforce assets like Flows, Apex, MuleSoft APIs, and prompt templates”, with batch testing in the builder.³

Suite builders start with your users, records, and permissions already in place, which makes them the shortest path for agents that work inside that suite. Agents whose work spans many vendors’ systems rely on connectors back into the suite.

Developer frameworks

Frameworks are code libraries for engineers. LangChain describes LangGraph as “an agent runtime and low-level orchestration framework”, with “human-in-the-loop checks to steer and approve agent actions”, built-in memory, and control flows from single agents to “multi-agent, hierarchical” designs.⁴ CrewAI describes itself as a way to “build collaborative AI agents, crews, and flows”, with sequential, hierarchical, or hybrid processes and human-in-the-loop triggers.⁵

Frameworks give engineers the most control over how an agent reasons. They suit agents that are part of your own product.

Cloud agent services

Cloud providers run the infrastructure for agents your developers write. AWS calls Amazon Bedrock AgentCore “the platform for production AI agents”, and says you can start with LangChain, the OpenAI Agents SDK, the Claude Agent SDK, Strands, or your own framework, with any model.⁶ AgentCore covers authentication and access control for connections to MCP servers, knowledge bases, internal APIs and Lambda functions, and shows what steps an agent took and what it called.⁶ It suits engineering teams that want to run code-first agents in production on AWS.

AI agent builder vs framework

The question most teams actually face is whether to build in a framework or a builder. The difference is how much of the system you own.

With a framework, your engineers write the agent and then build everything around it: hosting, a connector for each system, credential storage, per-user permissions, approval steps, logging, evaluation, and the on-call rota when something breaks at 2am. That is the right trade when the agent is your product, and its reasoning is what you compete on.

With a builder, those parts come with the product. You trade some control over the agent’s internals for not having to build and run the rest. That is usually the right trade when the agent’s job is to act across business systems: resolve tickets, update records, provision access, chase renewals.

Plenty of companies use both. A product team writes customer-facing agents in a framework, while IT and operations build internal agents in a builder. What they should share is one way of governing the tools those agents call.

Multi-agent systems

One agent with forty tools is hard to test and harder to trust. The common fix is several agents, each with a narrow job and a short tool list, coordinated by one that routes the work.

A coordinating agent receives “I’m starting Monday and can’t get into the expenses app.” It recognizes an access request, passes it to an IT agent with identity tools, and the IT agent checks the person’s role, asks the manager to approve, and grants the licence. A question about holiday allowance would have gone to an HR agent instead, with read access to HR policies and nothing else.

This keeps each agent’s permissions small and its behavior easy to test. Life360 runs one master agent with sub-agents for each department on Tray.ai.

Governance: running agents in production

Most agent projects stall between a working demo and production. The reason is rarely the model. It is the questions security, finance, and audit ask before an agent can touch real systems.

• Access. Each tool should do one job, scoped to specific operations: read accounts, not delete them. Sensitive tools should run with the requesting user’s own credentials, so the agent can never do more than the person asking.
• Approvals. Anything that moves money, changes access, or reaches a customer should wait for a named person to approve it, inside the channel where they already work.
• Audit. Every tool call should be recorded with the user, the tool, the credentials, the inputs, and the result, and those records should reach your security tools.
• Data protection. Personal data should be masked before it reaches a model that does not need it.
• Evaluation. Agents should be tested against real cases before release and after every change to instructions, tools, or model.
• Cost. Every agent run uses model tokens and platform usage. You should be able to see the cost per completed task and forecast it as usage grows.

Our AI agent strategy playbook covers how to run agents at enterprise scale, including who owns what.

AI agents and MCP

The Model Context Protocol (MCP) is “an open-source standard for connecting AI applications to external systems”, which its maintainers compare to “a USB-C port for AI applications.”⁷ An agent that supports MCP can call tools published by any MCP server, without custom code for each one.

For agent builders, MCP matters in two directions. Builders act as MCP clients, so an agent can use tools published elsewhere. And platforms can publish their own connectors as MCP tools, so agents built in Claude, OpenAI, Copilot Studio or your own framework can use them.

What MCP leaves to you is control. The protocol defines how an agent calls a tool. It does not decide which tools a given person’s agent may call, with whose credentials, or where the call is recorded. That is the job of an agent gateway. J.W. Pepper used Tray’s Agent Gateway to reduce 500+ MCP tools to about 20 governed workflows. Our explainer on everything you need to know about MCP covers the protocol itself.

AI agent examples and use cases by team

The agents that reach production first share a shape: a high-volume task, a clear finish line, and a few systems to touch.

• IT. Password resets, access requests, software provisioning, and ticket triage. Apollo’s IT agent on Tray.ai deflected 40% of tickets in its first two weeks.
• Customer support. Billing questions, order status, refunds within policy, and routing the rest to the right person with the context already gathered.
• Sales and RevOps. Researching an account before a call, updating the CRM after one, flagging stalled deals, and routing inbound leads. Our guide to building AI agents that connect to your CRM and marketing stack walks through one.
• Finance. Matching invoices to purchase orders, chasing missing approvals, and explaining variances from the ERP.
• HR and people teams. Onboarding checklists across HR, IT, and payroll, plus answering policy questions from the handbook.
• Security. Enriching alerts with context from several tools and opening a ticket with the evidence attached, with a person deciding on any response.

Start with one. An agent that reliably resolves one kind of ticket teaches you more than five that half work.

How to build an AI agent

Whatever builder you choose, the steps are the same:

1. Pick one task with a finish line. “Resolve duplicate-charge tickets” beats “improve support”.
2. Write the instructions. Say what the agent is for, what it must never do, and when to hand off.
3. Connect knowledge. Give it the policies and records it needs, and nothing it does not.
4. Give it narrow tools. A few specific actions, scoped to the operations the job needs, rather than broad API access.
5. Add approvals. Put a person in front of anything consequential.
6. Test on real systems. Run real cases, then break a tool on purpose and see how the agent recovers.
7. Release small and watch. Give it to one team, read the logs, check the cost per task, then widen.

How to choose an AI agent builder

Five questions narrow the field quickly:

• Where does the agent’s work live? Inside one suite, start with that suite’s builder. Across many systems, look at builders on an integration platform.
• Who will build it? Business and IT teams need a no-code builder. Developers building agents into a product will want a framework or cloud agent service.
• What can it act on? Count the systems the agent must reach, and check how each builder connects to them.
• How is it governed? Ask every vendor to show scoped tools, per-user credentials, approvals, and the audit log working.
• What does a completed task cost? Ask for the cost at your volume, including the integrations the agent needs.

How to choose a no-code AI agent builder turns these into a full checklist with a test plan, and the 10 best AI agent builders for enterprise compares ten products against them.

How Tray.ai builds agents

We make Tray.ai, so weigh this section with that in mind.

Tray.ai builds agents with Agent Builder, a no-code builder for conversational or autonomous agents with knowledge, tools, guardrails, and audit.⁸ You start from a template, such as a knowledge agent, an IT service management agent, or a support ticket agent, or from a blank agent. You connect data sources the agent can search, and add tools from templates or built as Tray workflows, with code steps where a job needs them.⁹ The same agent can run in Slack, in Microsoft Teams, or behind an API endpoint, and you can use Tray’s native models or bring your own from providers such as OpenAI and Anthropic.^9,10

The difference is what the agent acts through. Tray connects to 5,000+ apps, databases, APIs, and services, and agents use the same connectors and workflows as your integrations, with one access model and one audit log. Agents can work together, with a master agent coordinating sub-agents. Agent Gateway turns Tray connectors into governed MCP tools for Claude, OpenAI, Copilot Studio and other clients. Each call is tied to a named user, can run on that user’s own credentials, and is logged in one audit log, and composite tools do a multi-step job in one call for up to 10x lower token costs.¹¹

Analysts have recognized this approach. IDC named Tray.ai a Major Player in the IDC MarketScape: Worldwide Agentic AI Platforms 2026 Vendor Assessment, and Gartner named Tray.ai a Pioneer in its 2026 Emerging Market Quadrant for No-Code Agent Builders.^12,13

The trade-offs: Tray.ai is managed cloud only, and Agent Builder is switched on for your workspace through your account team. If your agents will live entirely inside Microsoft 365 or Salesforce, the native builder has context Tray can’t match. To try the platform the agents act through, start a free 30-day trial with 1 million Tasks, no card, and no sales call.

Sources

1. Microsoft, Copilot Studio overview, read 8 November 2026: https://learn.microsoft.com/en-us/microsoft-copilot-studio/fundamentals-what-is-copilot-studio
2. Microsoft, Extend your agent with Model Context Protocol, read 8 November 2026: https://learn.microsoft.com/en-us/microsoft-copilot-studio/agent-extend-action-mcp
3. Salesforce, Agentforce Builder, read 8 November 2026: https://www.salesforce.com/agentforce/agent-builder/
4. LangChain, LangGraph, read 8 November 2026: https://www.langchain.com/langgraph
5. CrewAI documentation, read 8 November 2026: https://docs.crewai.com/
6. AWS, Amazon Bedrock AgentCore, read 8 November 2026: https://aws.amazon.com/bedrock/agentcore/
7. Model Context Protocol, What is the Model Context Protocol (MCP)?, read 8 November 2026: https://modelcontextprotocol.io/docs/getting-started/intro
8. Tray.ai, Agent Builder: https://tray.ai/platform/merlin-agent-builder/
9. Tray.ai documentation, Agent Builder getting started: https://tray.ai/documentation/platform/artificial-intelligence/agent-builder/getting-started
10. Tray.ai documentation, Agent Builder interaction channels: https://tray.ai/documentation/platform/artificial-intelligence/agent-builder/interaction-channels
11. Tray.ai, Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/
12. IDC MarketScape: Worldwide Agentic AI Platforms 2026 Vendor Assessment (#US54140926, 12 October 2026), as cited on tray.ai: https://tray.ai/
13. Gartner, Emerging Market Quadrant for No-Code Agent Builders, Established Vendors, 8 June 2026, Jason Wong, Keith Guttridge, Eric Goodness, Kelli Smith, Justin Tung. See https://tray.ai/blog/gartner-pioneer-no-code-agent-builders-2026/

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally. All rights reserved. Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.