Why organisations need an enterprise agent orchestrator

By Isaac Muthui, CEO, Tamalaki Business Network Ltd. Originally published at factoraerp.com.

AI agents can now draft replies to customers, open pull requests, update CRM records and prepare deployments. That is useful. It also raises a question most organisations have not answered yet: who is in charge of the agents?

If every team picks its own tools, connects its own accounts and gives its agents whatever access seems convenient, you end up with dozens of automated workers that nobody can list, budget for or audit. An enterprise agent orchestrator exists to fix that.

The problem: agent sprawl and shadow AI

Staff are not waiting for a formal AI strategy. In Microsoft and LinkedIn's 2024 Work Trend Index, 78% of people who use AI at work said they bring their own AI tools, and the figure was 80% at small and medium-sized companies. The same report notes that this puts company data at risk.

Agents make this sharper, because an agent does not just answer a question. It acts. Typical symptoms:

• Agent sprawl. Agents live inside separate apps, each with its own login, keys and settings. Nobody has one list of what is running.
• Shadow AI. Personal accounts and API keys are used for company work, outside any policy.
• No oversight. There is no single record of what an agent did, which model it used, what it cost or who allowed it.
• Siloed tools. Email, CRM, code and cloud each get their own automation, with no shared rules for what needs a human.

The risk is not theoretical. The OWASP Top 10 for LLM Applications (2025) lists Excessive Agency as a top risk: agents with more functions, permissions or autonomy than they need can take damaging actions after a hallucination or a prompt injection. And Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls.

What an orchestrator does

An enterprise agent orchestrator is the control layer between your people, your agents, the AI models they call and the systems they touch. In practice it should:

1. Tie every agent to a named person and team, so ownership is never in doubt.
2. Route model calls through one gateway, with budgets and keys managed centrally.
3. Decide which tools and connectors each agent may use, and keep everything else switched off.
4. Stop high-impact actions for a human: sending email, posting externally, deploying, paying, writing to production.
5. Record everything in a log that cannot be quietly edited.

Why it matters

• Control. You decide which models and tools are allowed, per team and per person, instead of discovering them afterwards.
• Audit. When a customer, auditor or board member asks "who approved this?", there is an answer.
• Cost. Spend is capped and visible before it becomes a surprise invoice.
• Security. Credentials stay on the server, not in prompts or personal accounts. This is the "least privilege" advice OWASP gives for agents.
• Human approval. OWASP recommends human-in-the-loop approval for high-impact actions. An orchestrator makes that the default rather than an afterthought.

How TEAO approaches it

At Tamalaki Business Network we built TEAO, the Tamalaki Enterprise Agent Orchestrator, as the agent desk for our own team at agents.tamalakibn.com. Its sign-in page sums up the design: named people, gated actions, append-only ledger. TEAO is an MVP, and this is what it does today.

Named people own agents. Staff are organised into departments and roles. Agents come from templates matched to a department and role, and a person is added by invitation. No passwords are seeded. Sign-in supports an authenticator app with backup codes, and single sign-on can be added in front.

One gateway for models, with budgets. Agents call models through a gateway that routes between tiers. Paid models stay off until a super admin enables them. Spend is counted per month, with caps per department and per person. When a cap is hit, a call can either drop to a cheaper tier or pause and raise an alert. Department heads can lower a member's cap but cannot raise it above the department cap. Jobs prefer an enabled free model and escalate to a paid one only when the budget allows, and the reason is written on the job timeline.

Gated actions. Every job writes a plan first. Sending mail, posting externally, deploys, payments and production writes stop for a person. So does a job that goes over its cost threshold or needs a tool or connector that has not been granted. Approvers can reject a job back for revision, or edit the text and then approve it. Approval rights follow the organisation. For example, an administration head can approve outreach sends but not payments.

Connectors with least privilege. TEAO connects to email, GitHub, a CRM, web search and files, and has sign-in patterns for services such as Google, Microsoft, Zoho, Slack, Notion, HubSpot and Canva. Credentials come from connector settings or the server environment and are never placed in the model prompt. Some limits are built in: the CRM connector never deletes, pushes to the main branch are refused, and a pull request opens only after approval.

Redaction, tracing and sandboxing. Every model call is traced after a pass that redacts keys, card numbers and passwords. Card numbers are never stored. Code runs in a locked-down sandbox with no network, a read-only file system and tight memory, CPU and time limits.

An append-only, hash-chained ledger. Sign-ins, jobs, approvals (including what was approved), connector and model changes, budgets and exports are written to a hash-chained activity log. Each agent run records the person, agent, model, tools used (with secrets redacted), tokens, cost, duration and outcome. Operations shows whether the chain is still intact, the log can be exported as CSV or PDF, and records are kept for at least two years.

A live console with working modes. A technical console shows running jobs. Each job can run in Observe, Assist, Autopilot within guardrails, Troubleshoot, Build or Human takeover mode. Whatever the mode, the gated actions still wait for approval, and every swap of agent, model or tool needs a stated reason.

TEAO is self-hosted with Docker Compose and is designed to fit on one modest cloud server. Staff can also open the desk in a TEAO desktop app for Windows and macOS.

A short checklist for choosing an orchestrator

Before you adopt any agent platform, ask:

• Is every agent owned by a named person, and can you list them all?
• Do model calls go through one gateway, with per-team and per-person budgets?
• Are paid models and new connectors off by default?
• Which actions always require human approval, and can you change that list?
• Are credentials kept out of prompts and redacted from logs?
• Is the audit log tamper-evident and exportable?
• Can a person take over a running job at any point?
• Can you self-host it, or at least control where your data and logs live?

If the answer to several of these is "no" or "we're not sure", you have agents but not yet an operating model for them.

Next step

TEAO is how we run agents at Tamalaki: people stay accountable, risky actions wait for a human, and every step is on the record. To see how this approach could work in your organisation, visit agents.tamalakibn.com or write to [e-mail].