A chatbot answers in a window. An internal agent runs a task with tools, limits and a definition of done. Mixing the two puts a fluent dialogue into production that leaves no trail when it fails.

They are not the same object

A chatbot is an interface. It can help someone query a policy or get oriented. Its success is visible in the conversation.

An internal agent is a bounded worker: it reads a case, queries allowed sources, proposes or runs a step and leaves a record. Its success is visible in the system of record, not in how eloquent it sounds.

What to require before calling it production

Production needs more than a fluent demo. You must be able to say who authorises each action, which tools the agent may touch, what happens if a destination does not respond and how an incorrect step is undone.

If those answers do not fit on one page, the agent is still a prototype. Onezix Systems treats that page as part of the architecture, not as documentation written later.

  • Task scope: one family of cases, not “everything internal”.
  • Allowed tools and forbidden tools.
  • Permissions inherited from the person or role, not a wide “make it work” grant.
  • A log of inputs, outputs and intermediate decisions.
  • A mandatory human point for irreversible or sensitive actions.
  • A way to stop or revert when the result does not fit.

Evaluate with real cases

An agent is not validated by a demonstration chat. It is validated with a sample of cases the team already resolved: easy, ambiguous and exceptional. The test is whether the proposal matches what an expert operator would have done, or whether it escalates in time.

That sample is kept. It lets the test be repeated when instructions, models or integrations change. Without a stable sample, every improvement is an opinion.

The chatbot can be the door, not the system

It is reasonable for a person to ask in natural language. That does not make the chat window the place where payments, CRM changes or client-facing sends are executed.

The interface queries. The agent, if it exists, operates behind it with rules. Mixing both in one text box is what makes so many internal deployments fragile.

Risks a politer tone will not fix

Hallucinating a fact, skipping a permission or closing a case without evidence is not fixed by a kinder prompt. It is fixed with perimeter, sources and supervision.

It is also not fixed by giving the agent more tools. Each new tool widens possible harm. Serious design starts by removing capabilities the task does not need.

How Onezix Agents approaches this

Onezix Agents are modules for specific tasks — support, administration, operations, documentation, follow-up — inside Onezix OS. They are not sold as a general assistant that “talks to the company”.

Onezix Systems deploys them with the same requirements as the rest of the infrastructure: permissions, sources, workflows and a human operator wherever the action changes the state of the business.