Reseller or Operator? Who Actually Runs Your AI Agent

A reseller sells you access to a platform that someone else built and runs, and its responsibility usually ends at the invoice and basic onboarding. An operator takes responsibility for how your agent behaves week after week: its memory, tools, permissions, monitoring and repairs. To tell them apart, ask who investigates and fixes the agent when it does something wrong on an ordinary Tuesday.

Key takeaways

• A reseller supplies access to a platform built by someone else. An operator is accountable for how your agent runs after launch.
• The test is not the brand on the invoice. It is who changes, monitors, repairs and can explain the agent's behavior.
• Ask for named duties, response paths and evidence of how work is done, not feature lists.
• Reselling can be a fair model if the contract says plainly what the reseller does not control.
• Get the answers in writing before you sign, so scope, access and exit terms match what was described.

What is the real difference between a reseller and an operator?

An AI agent is not one product. It is a stack: a model, a platform that hosts it, a configuration that gives it a role, memory, integrations with your tools, permissions, and someone who watches it work.

A reseller holds a commercial relationship with the owner of one of those pieces, usually the platform, and passes it on with some setup help. An operator holds responsibility for how all the pieces work together inside your company. Both can be honest businesses. The trouble starts when you believe you bought the second and received the first.

Reselling is not a criticism in itself. If you have a capable internal team that wants a platform license and will run the agent on its own, a reseller can be exactly right. The mismatch is about expectations: a company that expects someone to own outcomes but signs with someone who owns a license.

Why does the difference matter after launch?

On launch day the two look identical. Both show a working demo, both connect a mailbox or a document store, both say the agent is live. The difference appears in the following months, when ordinary events arrive:

• The underlying model changes behavior after a provider update, and answers shift in tone or accuracy.
• An integration breaks because a connected tool changed its authentication or data format.
• A person leaves, and their access to the agent should be removed the same day.
• The agent is asked to do something slightly outside its role, and someone must decide whether it may.
• A wrong answer reaches a customer, and someone must find out why.

Each event needs a person with the access, context and authority to act. With a reseller, that person is often you, a general support queue at the platform vendor, or nobody in particular. With an operator, the person is named in advance. The recurring work is laid out in what managed AI services include.

Which questions reveal who actually runs your agent?

Ask these in a call, then ask for the answers in writing. Pay attention to whether each answer names a person, a process or a document, or only a feature.

• Who is on the other side when the agent gives a wrong answer, and how do I reach them? A reseller points to a ticket queue or documentation. An operator names a role and a response path.
• Who holds administrator access to the platform and to each connected tool? You need to know whether your company owns the accounts or the vendor does.
• Who decides which permissions the agent has, and how often are they reviewed? Look for a review routine, not a one-time setup.
• What do you monitor on my agent, and what do you do when monitoring flags something? Operators can describe logs, traces and checks on their own work. Resellers describe the platform dashboard.
• Which parts of this setup do you control, and which belong to another company? A direct answer lists the model provider, the host and any other dependency.
• What happens when the underlying model or platform changes? Operators have a way to test a change before it reaches your users.
• If I leave, what do I take with me: memory, configuration, instructions and logs? This shows whether the work is portable. See how to avoid AI vendor lock-in.

These questions follow ideas from established practice: least privilege and deny-by-default in OWASP authorization guidance, and the observability principle that you should be able to understand a system from the data it emits. A vendor that cannot discuss either is probably not the one running the system.

What do strong and weak answers sound like?

Strong answers are specific about roles, cadence and limits. A named engineer reviews the agent's permissions on a regular schedule and sends you the result is concrete. We follow best practices is not. Operators also admit limits: they say what they will not do and which risks sit with the model provider.

Weak answers tend to share a few traits:

• They describe platform features when you asked about people.
• Support is described only as documentation, community forums or a general ticket system.
• There is no written description of who approves changes to the agent's instructions or tools.
• The vendor is reluctant to say which third parties are involved.
• Success is described as adoption of the license, not as an observable outcome for a defined role.

None of these is fatal alone. Several together suggest a reseller presenting itself as an operator. Risk guidance such as the NIST AI Risk Management Framework puts weight on assigned roles and accountability, and the same logic applies to a vendor relationship: if no one is assigned, no one is accountable. A longer list of warning signs is in red flags when hiring an AI implementation partner.

What does the difference look like in practice? An illustrative scenario

This is an illustrative scenario, not a real case. A distribution company wants an agent that answers internal questions about order status. Two vendors give similar demos. Vendor A is a reseller. Vendor B is an operator.

A few months after launch, the company's order system changes how it labels shipment statuses. The agent keeps answering with confidence, but the answers are now out of date.

With Vendor A, the operations manager opens a ticket with the platform support queue, which replies that the platform is working normally. The manager then has to work out whether the problem sits in the instructions, the integration or the data, and who is allowed to change which. With Vendor B, monitoring had already flagged a rise in unresolved lookups. A named person traces the issue to the status mapping and proposes a change. The manager approves it, and it is tested before it goes live.

Same agent, same model. The difference is who owned the whole system.

How does Be Human handle operation?

Be Human designs, implements and operates the agent as one service. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. After launch, managed operations can include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. The work is remote, in English and Portuguese, and the agent's identity, memory, channels, tools and permissions stay under human control on your side.

How do you test a vendor's answers before you sign?

Use this plan to turn conversation into evidence. It takes a few meetings, not a long project.

• Step 1: Send the seven questions before the call, so answers are prepared and recorded.
• Step 2: Ask the vendor to mark each layer (model, hosting, configuration, integrations, monitoring, incident response) as theirs, a third party's or yours.
• Step 3: Ask for a walk-through of one past incident or change, with details removed, and listen for who did what.
• Step 4: Ask to see how a change request is submitted, approved and tested.
• Step 5: Check that the access you need, such as administrator accounts and data exports, belongs to you under the contract.
• Step 6: Write the agreed split into the statement of work. The section-by-section guide to an AI agent statement of work shows where it belongs.
• Step 7: Start with a small, defined pilot and watch how the vendor behaves when something goes wrong.

If the answers hold up in writing, you have either a real operator or a reseller that is honest about its role. Both are workable. Unclear responsibility is the thing to avoid.

Frequently asked questions

Is an AI reseller always a worse choice than an AI service provider? No. A reseller fits a company that has people able to configure, monitor and maintain the agent itself. The risk is paying for operation you will not receive.

Can one vendor be both a reseller and an operator? Yes. Many operators build on platforms and models owned by others, so the useful question is not whether third parties are involved. It is who is accountable for the agent's behavior in your company once they are.

Who should own the accounts and credentials the agent uses? Your company should own them, or at least hold administrator rights that the vendor cannot remove alone. Ownership keeps the agent portable and lets you end the relationship without losing access to your own data and configuration.

What if my existing IT provider offers to resell an AI platform? Ask the same questions. An IT provider may run infrastructure well, but agent behavior, memory and evaluation are a different kind of operating work. Check whether anyone is assigned to that work and whether it appears in the contract.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.