AI agent builder: what to look for when the agents have to run inside your own environment

An AI agent builder is a tool you use to build AI agents. You define the agent, give it tools and knowledge, and the platform runs it. Most products do the building part well. The question that decides the purchase is a different one: where does the agent run, and who owns what it leaves behind?

If your agents have to run inside your own environment, that question comes first. Product pages answer it last. This guide covers the parts an agent builder must give you, the four questions to ask, and the three ways these platforms are delivered.

Five things to ask for. If one is missing, your team builds it later.

A way to define agents, tools and knowledge. Each agent needs a job, an instruction, the tools it may call, and the documents it may read. All four in one place, or nobody can review the agent before it goes live.

A runtime that runs them. The platform has to start the work, keep its state, retry a failed step, pass work between agents, and stop when something is wrong.

A record of what ran. The prompts, the tool calls, the model answers and the result. You need it to debug this week, and someone will ask for it next year.

Permissions on what the tools may touch. An agent is only as safe as the tools you give it. The platform has to say who can create a tool, who can change a flow, and which systems a tool may reach.

Ask whether it can stop and wait for a person. On the steps you choose: sending money, writing to a system of record, messaging a customer. Ask to see it switched on, in the version you would install.

1. Where does it run?

Ask for the deployment options in writing. "We support on-premises" can mean a full install on your servers. It can also mean an agent inside your network that still calls the vendor's cloud to think.

2. Who can read the code?

There are three answers. Nobody outside the vendor. Anyone, for part of it. Anyone who receives the code, under a licence. If your security team has to review what touches your data, the first answer ends the conversation.

Watch the words "open source". Several platforms here are source-available, which is not the same thing: you can read the code and run it, with limits set by the licence. Read the licence file, not the marketing page.

3. What does the record contain, and who owns it?

Two questions, and vendors often answer only the first. For contents, ask what one entry holds: the prompt, the tool calls and the model answer, or only "step 4 finished". For ownership, ask where the rows are written. If the record lives in the vendor's database, you read it through their console for as long as you pay. If it lives in your database, it is yours to keep, export and delete.

4. What leaves the network?

List every outbound call the platform makes: the model endpoint, the service that turns documents into vectors for search, voice if you use it, and anything the product sends home about itself. Then ask which of those you can point at your own servers.

A tool you build is your own responsibility. If you write a tool that calls a public API, that call leaves your network because you told it to. That is your choice to make.

This table compares delivery models, not vendors. Products move between columns over time, so check the current tier list.

Question	Hosted SaaS	Self-hosted, open core with paid governance	Self-hosted, source-available
Where does it run?	The vendor's cloud.	Your servers for the core. Some paid parts may still need the vendor.	Your servers.
Who can read the code?	Nobody outside the vendor.	Anyone, for the open core. The paid layer is usually closed.	Anyone who receives the code, under the licence.
Where does the record live?	The vendor's database.	Your database for the core. Longer retention and log streaming may sit in a paid tier.	Your database.
Access control	Included in the price.	Basic roles may be in the free edition; single sign-on may be paid. Check the tier list.	Set by the vendor's tier list. Read it.
What can you change?	The settings the vendor exposes.	The open core.	The code, for your own use, within the licence.
What do you depend on?	The vendor staying available.	The vendor, for the paid layer.	The code you hold.

None of the three is wrong. Hosted SaaS starts fastest. Open core gives you the code for the common case and sells the parts a large company needs. Source-available gives you the code and the deployment, with the limits in a licence instead of a tier list.

EpicStaff runs on your infrastructure. It is source-available under PolyForm Perimeter 1.0.0: read it, run it, modify it for your own use; the restriction is commercial competition, not inspection. Role-based access control is in the source-available tier, not the paid one. The record of prompts, tool calls and model responses is written to your own PostgreSQL database, and you can export it as JSON or CSV. EpicStaff connects out only to the providers you configure keys for. Tools do what you tell them: a tool you build or enable that reaches the internet is your choice and your configuration. The model adapter calls the LLM endpoint you point it at.

If you are comparing us with one specific workflow tool, we keep a dimension-by-dimension comparison with n8n.

A visual builder is enough more often than engineers expect. It fits when the work is a shape: this step, then that step, ask a person here, write the result there. Then the people who own the process can change a step without a ticket.

You need code in three cases. First, an internal system with its own rules: paging, retries, odd error codes, a data model nobody outside your company has seen. Second, shaping data: cleaning, matching, joining, checking a number against a second source. Third, reuse: three flows needing the same action should be one tool with one owner.

So look for a platform that gives you both. An engineer should be able to add a tool in Python, and tools should also arrive over MCP. MCP, the Model Context Protocol, is a common way to connect an existing tool to an agent, so you do not write a new adapter for each platform. In EpicStaff, engineers add tools in Python and connect systems over MCP.