AI agents for business without code: a passport, not a program

It’s 10:40 on a Tuesday, and the operations manager is watching a coordinator do the same thing for the third time this morning. Open the customer thread. Download the photos of the shipping documents. Type the truck number, weight and route into the order system. Attach the files. Go back to the chat and send the customer an order number. Twenty minutes per order, forty orders a day. “This is exactly what AI should be doing,” she thinks. Then she remembers the engineering team is booked through spring.

This post is about AI agents for business without code. The short version: you don’t program an agent, you describe it. We call that description the agent’s passport. Below is what goes into it, how you build one by talking to an assistant, and why this is safer than “giving the AI access to everything.”

Why agents used to need developers

Until recently, a new AI agent meant a software project. Someone wrote the glue between a model and your CRM or ERP, deployed it, and then fixed it every time anything changed. Want to tweak one line of the greeting? File a ticket. Want the agent to do one more thing? Another ticket.

The other extreme was the visual builder: drag boxes onto a canvas, connect them with arrows. It looks easy until the flow hits forty boxes. After that, only the person who drew it can follow it.

Over 2025 and 2026 the industry settled on a third way. An agent is a description, plus tools, plus strict procedures, and you build it in a conversation: plan, confirm, test, publish. That’s how agent building works in Microsoft Copilot Studio. OpenAI announced it will retire its visual Agent Builder on November 30, 2026, in favor of describing agents in plain language and writing code only where code is truly needed. The agent builder in AGENTUS follows the same principle.

An agent is a passport, not a program

A passport is a document with a handful of plain-language parts. One engine runs every passport. A new agent, or a change to an existing one, is just a new version of the passport. No code, no deployment.

Passport section	What it holds	Example: an order-entry agent
Role and instructions	who it is, how it talks, what it never does	“You’re the service desk. Keep it short. Never quote prices.”
Connections	which systems it can reach	your order system, CRM, knowledge base
Actions	3–10 hand-picked operations with clear names	“create order,” “attach document,” “check status”
Procedures	strict steps for the jobs that matter	creating an order from a chat thread
Settings	what a human has to fill in	an access key for the order system
Channels	where the agent works	customer conversations, team chat, a schedule
Test cases	what it’s checked against before going live	20 real conversations from last month

Here’s a closer look at the parts that matter most.

Connections and actions

A connection is created from the external system’s API description or from an MCP server (the emerging standard for plugging tools into AI agents). But the agent doesn’t get everything the system can do. Out of dozens of possible operations, you pick the 3–10 you need, and each one gets a human-readable name.

Every action is tagged read or write. Reading is fine on its own. Anything that changes data in another system waits for a person to say yes by default. And it runs exactly once: if someone double-clicks, or the network hiccups and the request repeats, you don’t end up with two orders.

Procedures: the model reads, the system acts

For important work, the agent doesn’t get to improvise. A procedure is a fixed sequence of steps. Take the order from the opening scene:

1. The coordinator selects the relevant messages in the thread.
2. The agent gathers their text and attachments.
3. The model reads the documents and fills in the form: truck, cargo, route.
4. If something is missing, the agent asks the coordinator instead of guessing.
5. The coordinator sees a finished card with a “Create” button.
6. After the yes, a fixed step — no model involved — sends the order to the order system, exactly once.
7. The agent posts the order number back to the customer.

The model does what it’s good at: reading and sorting information into fields. The submission is handled by a step that can’t get creative.

Keys the model never sees

Settings fields appear in the passport automatically, based on the connection. If the order system needs an access key, the passport asks for it and tells you where to find it. The key is stored encrypted and inserted on the server at call time. The model never sees it, so it can’t accidentally paste it into a chat.

Building an agent by conversation, in five steps

In AGENTUS, you build agents by chatting with an assistant. The flow is always the same:

1. Say what you need. “Build an agent that creates an order in our system from the messages I select.”
2. Answer the follow-up questions. The assistant asks about the gaps: required fields, who approves, which channel the agent lives in.
3. Read the plan. The assistant explains, in plain English, which connections, actions and steps it will set up and which settings it needs.
4. Say yes and run a test. A new passport version is created. The test run uses real conversations in a sandbox: calls to the external system are recorded but never sent. You see exactly what the agent would have done.
5. Turn it on. The agent goes live. Every version is kept, and you can roll back with one click.

If you prefer to configure things by hand, the agent card is still there. It’s the same for every agent and has six blocks: identity, behavior, tools, model and budget, memory, channels.

Five guardrails every agent needs

An agent that talks to customers and touches company data has to be predictable. Here’s what we treat as non-negotiable.

A budget. Each agent has a daily and monthly cap on AI spend, plus a rule for what happens at the cap: stop, switch to a cheaper model, or hand off to a person. We cover how model spend is tracked in “one door to every AI model.”

Answers without making things up. The agent answers in four tiers: first a company fact sheet with approved facts, then ready-made answers, then the MEMUS knowledge base with a link to the source document. If none of those has the answer, the question goes to your people in CHATUS, and the customer hears “let me check with a specialist.” We explain how the agent learns from those questions in “how our AI sales agent learns.”

Memory you control. The agent remembers working context and things it has learned. A manager can tell it to forget the working context or forget what it learned, and can schedule automatic cleanup.

Modes for customer conversations. The agent can run on autopilot, on call (a rep selects messages and asks for help; the agent proposes, the rep confirms), or in notes-only mode, where it just leaves suggestions. Starting on call is usually the smart move.

A seat on the org chart. An AI employee sits in your org structure like anyone else and gets its department’s permissions — nothing more. A sales agent can’t see accounting simply because sales doesn’t have access to accounting.

What if you really do need code

Some logic doesn’t fit into actions and steps: an unusual calculation, an obscure file format. This is where you need to be careful.

The riskiest approach is running custom code inside the main service. In 2026, that’s how attackers took over the popular agent builders Langflow and Flowise: code running on the server without isolation let outsiders take control.

So in PRANUS, when code is needed, the AI assistant writes it, not a person. It runs in a locked sandbox: no keys, no network access, only data in and data out. Calls to outside systems still go through the engine, with approvals and protection against duplicates. In our experience, most everyday jobs — orders, status checks, documents, customer replies — need no code at all.

Checklist: is your process ready for an AI agent?

Before you build, run the process through six questions:

• It happens at least several times a day and looks roughly the same each time.
• It’s clear where the agent gets its inputs: a chat, documents, a customer record.
• It’s clear where the result goes and who’s allowed to approve it.
• You have 10–20 real examples to test the agent against.
• The knowledge needed to answer is written down somewhere, not just in one person’s head.
• You’re willing to spend the first few weeks in “agent proposes, human decides” mode.

Five out of six checked? The process is a good fit. If the knowledge piece is missing, start with the knowledge base. You can build it from your conversation history, and the agent can lean on it from day one.

What changes for managers

An agent stops being a development project and becomes a team member you configure in plain language. Changing its tone, adding an action, tightening its budget — each is an edit to the passport, visible in the history and reversible.

Most importantly, people stay in control. Anything written to an outside system goes through a yes. Anything the agent doesn’t know goes to a specialist. Everything it spends shows up as a number.

We set up the first agents — front-line support, a sales assistant, an order-entry agent — together with you during the 14-day implementation. If you’d like to see a passport built around one of your own processes, book a demo and we’ll walk through a live example.