Cookie Preferences
We use cookies to enhance your experience, analyse site traffic, and support our marketing. You can customise your preferences or accept all cookies. See our Privacy & Cookie Policy for details.

MNB Tech

Agents vs Humans: The future of workforce

AI & Automation

Enterprise agents will not replace humans; they will restructure work. We outline the architecture, controls and roadmap to deploy safe, productive AI workcells.

9 min read

TL;DR

  • Agentic automation will shift work from tasks to outcomes, with humans supervising, arbitrating risk and owning customer trust.
  • The winning pattern is a controlled “agent workcell” that integrates policy, observability, tools and human-in-the-loop checkpoints.
  • Cost, latency and risk are manageable with deterministic controllers, least-privilege tools and model-agnostic gateways.
  • The jobs debate is misframed: roles will be recomposed into higher-leverage human+agent hybrids rather than eliminated wholesale.
  • Start with narrow, high-volume, low-regret processes; expand as governance telemetry proves stability.

Abstract & Executive Observations

The question “will agents take our jobs” is reductive. In enterprise settings, agents will reshape job content faster than they remove headcount. We see three converging trends: first, mature tool-use and planning in modern LLMs enables multi-step work across APIs and documents; second, enterprise integration patterns (service buses, policy engines, observability) are now agent-aware; third, boards are mandating measurable productivity without compromising assurance. The disconnect is that many pilots bolt a clever agent onto legacy processes without rethinking control planes or work design. That produces demos, not dependable throughput.

Our thesis: enterprises should deploy agentic workcells—bounded, policy-enforced automation domains—where agents orchestrate tools under deterministic supervision, with humans governing escalations and exceptions. This reduces toil, increases cycle time reliability, and creates a data exhaust that feeds optimisation. The organisations that win will design jobs around judgement, relationship and risk, while instrumenting agents like any other production software. This is not “AI employees”; it is regulated autonomy, engineered.

The Current Architectural Challenge

Most “agent” proofs-of-concept fail when they meet enterprise constraints. Latency is unpredictable because the agent loops without a deterministic controller. Security crumbles when tools are over-permissioned or prompts are data-bearing. Costs spike as every step hits a frontier model without caching or low-rank routing. Observability is poor: there is no lineage from request to action to outcome, making audit and root-cause analysis impossible. And human-in-the-loop is often tacked on, not designed, leading to “approval theatre” rather than meaningful oversight.

We have observed three recurring failure modes across anonymised engagements: - Orchestration sprawl — An LLM both plans and acts, interleaving tool calls with planning tokens. Without a separate controller, retries and backoffs are chaotic. - Data leakage and prompt injection — Agents reading from untrusted content execute malicious instructions via tool APIs because there are no content-safety gates or output sandboxes. - Incoherent ROI — Costs dominate benefits due to lack of tiered model routing, insufficient batching and no partial result caching.

The hidden cost is operational toil: SREs end up treating agents as unknowable black boxes. The fix is architectural: separate concerns, enforce least privilege, instrument thoroughly, and treat the agent as a worker inside a governed cell with explicit inputs, outputs and controls.

Technical Visualization 1: Agentic workcell in the enterprise stack

graph TD U["User or System Trigger"] C["Controller (Deterministic Orchestrator)"] S["Supervisor Agent"] L["LLM Gateway"] P["Policy Engine"] V["Vector DB"] O["Observability & Tracing"] B["Service Bus"] T1["Tooling API: CRM/ERP"] T2["Tooling API: "Docs & Knowledge""] T3["Tooling API: "RPA/Legacy""] H["Human Reviewer"] U --> C --> S --> L S --> V C --> P C --> B B --> T1 B --> T2 B --> T3 C --> O S -->|Escalation| H H -->|Decision| C T1 --> O T2 --> O T3 --> O L --> O P --> O

Figure 1: A bounded “workcell” with a deterministic controller separates planning and acting, routes model calls via a gateway, enforces policy, and instruments every hop.

Interactive walkthrough: the same workcell, live

Static diagrams show structure; they don't show what happens when a request actually moves through the system. Step through it below — each stage highlights what's being decided and why, with data visibly flowing between control points.

Architecture Blueprint 2: Human-supervised agent workflow

sequenceDiagram actor Human as Business User participant Controller participant "Supervisor Agent" participant "Policy Engine" participant "LLM Gateway" participant "Service Bus" participant "Systems" Human->>Controller: Submit job with intent and constraints Controller->>Policy Engine: Check permissions and risk thresholds Policy Engine-->>Controller: Allow with guardrails Controller->>Supervisor Agent: Create plan, request tool list Supervisor Agent->>LLM Gateway: Generate plan outline LLM Gateway-->>Supervisor Agent: Plan and tool candidates Controller->>Service Bus: Dispatch tool calls Service Bus->>Systems: Invoke CRM or ERP or Docs Systems-->>Service Bus: Responses Service Bus-->>Controller: Results stream Controller->>Human: Review checkpoint if risk exceeds threshold Human-->>Controller: Approve or request change Controller->>Supervisor Agent: Finalise and compose output

Figure 2: A controller coordinates policy checks, planning, tool execution and human review, keeping the LLM in a bounded role.

Implementation Detail 3: Deterministic controller loop with guardrails

flowchart TD A["Task Received"] --> B["Policy Check"] B -->|Pass| C["Retrieve Context via RAG"] B -->|Fail| Z["Reject with Audit Log"] C --> D["Plan with LLM"] D --> E{"Tool Calls Needed?"} E -->|No| F["Draft Output"] E -->|Yes| G["Execute Tool via Service Bus"] G --> H{"Error or Risk Spike?"} H -->|Yes| I["Escalate to Human"] H -->|No| J["Aggregate Results"] I --> K["Human Decision"] K --> L["Adjust Plan or Abort"] J --> M["Compose and Validate"] M --> N{"Final Checkpoint?"} N -->|Yes| I N -->|No| Y["Deliver and Trace"]

Figure 3: The controller enforces a repeatable loop with explicit decisions, enabling retries, human input and full traceability.

Operational Flow 4: Core agent classes and responsibilities

classDiagram class Controller { +startJob(") +dispatchTool(") +checkpoint(") +trace(") } class Agent { +plan(") +reflect(") +compose(") } class Tool { +invoke(") +schema +scopes } class Policy { +evaluate(") +riskScore +constraints } class Memory { +retrieve(") +embed(") +sessionStore } class Monitor { +metrics(") +alerts(") +lineage(") } Controller --> Agent Controller --> Policy Controller --> Monitor Agent --> Memory Controller --> Tool

Figure 4: Separation of concerns keeps the LLM-focused agent small and auditable, while the controller, policy and monitoring handle enterprise-grade concerns.

Data Model 5: Agent job lifecycle

stateDiagram-v2 direction LR [*] --> Idle Idle --> Intake Intake --> Plan Plan --> Act Act --> Review Review --> Complete Act --> Error Error --> Recover Recover --> Review Recover --> Escalate Escalate --> Review Complete --> [*]

Figure 5: A clean state machine makes retries, escalations and completion criteria explicit for operations and audit.

Governance Framework 6: Controlled rollout timeline

gantt title Agent Workcell Governance Rollout dateFormat YYYY-MM-DD section Foundations Policy design and threat model :a1, 2026-06-15, 10d Observability and lineage setup :a2, after a1, 7d section Safety and Validation Red teaming and prompt security :b1, after a2, 10d Data protection and PII controls :b2, after a2, 10d section Pilot Narrow-scope pilot in one domain :c1, after b1, 21d Audit and ROI checkpoint :c2, after c1, 5d section Scale Multi-domain rollout with playbooks :d1, after c2, 30d Continuous audit cycle :d2, after d1, 90d

Figure 6: A staged plan with safety and audit gates reduces risk while building organisational confidence.

Risk Matrix 7: Risks, controls, assets and incidents

erDiagram ASSET { string id string owner string data_class } RISK { string id string category int severity } CONTROL { string id string type string status } INCIDENT { string id string date string impact } ASSET ||--o{ RISK : "has" RISK ||--o{ CONTROL : "mitigated_by" ASSET ||--o{ INCIDENT : "experiences" CONTROL ||--o{ INCIDENT : "applies_to"

Figure 7: Relating risks to assets, controls and incidents enables evidence-based governance and faster remediation.

System Context 8: Workforce evolution with agents

mindmap root((Workforce With Agents)) People Roles Supervisors Analysts Customer Leads Skills Promptcraft Tool Governance Exception Handling Process "Human-in-the-Loop" "Risk-Based Checkpoints" Playbooks Technology "Agent Workcells" "LLM Gateway" "Service Bus" Observability Data "Vector Stores" "Feature Stores" Lineage Risk "Policy Engine" "Red Teaming" "Audit Trails"

Figure 8: A holistic view of how people, process, tech, data and risk integrate around agentic workcells.

Implementation & Orchestration Strategy

  • Controller-first design — Treat the LLM as a planner and composer, not the process brain. The controller handles retries, timeouts, fan-out and backoff. We commonly use an event-driven controller backed by a queue and idempotent workers.

  • Model-agnostic gateway — Route calls via an LLM Gateway that supports policy-based model selection, safety filters and observability. Use small models for classification and routing, midsize for tool planning, and only escalate to large models when benefit exceeds cost.

  • Least-privilege tools — Define tools with explicit schemas and scopes. Avoid passing raw credentials in prompts. Bind tool invocations to service identities with short-lived tokens and narrow permissions.

  • RAG done right — Maintain retrieval layers decoupled from the agent. Chunk with domain-aware splitters, index with high-recall embeddings, and post-filter with structured constraints. Never stream untrusted content to tools without content safety checks.

  • Human-in-the-loop thresholds — Implement risk scoring that blends policy, anomaly detection and domain heuristics. Checkpoints trigger when thresholds are exceeded or when the agent’s confidence is low.

  • Observability and lineage — Every step emits spans and structured events: plan version, tool signature, inputs hash, outputs digest, model and token counts. Store artefacts for reproducibility.

Example minimal configuration:

workcell:
  controller:
    retry_policy: { max_attempts: 3, backoff_ms: 2000 }
    checkpoint_thresholds:
      risk_score: 0.7
      value_at_risk: 1000
  llm_gateway:
    routing:
      - match: { task: classify }
        model: gpt-4o-mini
      - match: { task: plan }
        model: mixtral-8x7b
      - match: { task: compose, complexity: high }
        model: gpt-4o
  tools:
    - name: create_ticket
      scopes: [ticket.create]
      auth: workload_identity
      schema: { inputs: { title: string, priority: enum[low,med,high] } }
    - name: search_kb
      scopes: [kb.read]
      auth: workload_identity
      schema: { inputs: { query: string, top_k: int } }
  policy:
    allowlists:
      prompts: ["no-secrets", "no-customer-PII"]
    denylists:
      tools: ["rpa_legacy_admin"]
  • Deployment patterns — Package each workcell as a deployable unit with its own policy set and dashboards. Use blue-green for agent updates and kill-switches wired to policy. Cache partial results in a shared store to short-circuit identical sub-tasks.

  • Change management — Version plans and prompts. Run offline regression on representative workloads before promotion. Attach A/B experiments to compare model combinations.

Security, Performance, and Trade-offs

  • Security — The largest risks are data exfiltration and tool misuse. Mitigate with input sanitisation, output sandboxing, content safety filters and strict egress policies. Adopt least-privilege for tools and rotate credentials automatically. Maintain tamper-evident audit logs.

  • Performance — Latency is driven by chaining depth and model choice. Reduce hops with deterministic controllers, cache embeddings and results, and use streaming where useful. Batch tool calls over the service bus and prefer parallel execution when dependencies allow.

  • Cost — Token spend can drift. Use routing tiers, compress context windows, and prune agent memory aggressively. Measure cost per outcome, not cost per token.

  • Limitations — Agents struggle with open-ended novelty, long-horizon planning and adversarial inputs. Human judgement, especially with ambiguous policy or ethical trade-offs, remains essential. Over-automation creates brittle systems; under-automation leaves value on the table. Strike a balance via risk-weighted checkpoints and continuous post-incident review.

Parting Thoughts on Industry Direction

In the next 12–24 months, we expect agent capabilities to feel more “software-like”: typed tools, policy-native gateways, and first-class lineage. Frontier models will improve planning, but governance and integration will be the differentiators. The workforce will evolve toward supervisory and exception-led roles, with productivity gains accruing to teams that recompose work around agentic cells rather than bolt AI onto legacy steps. If you are piloting agents, start with a narrow domain, implement the controller pattern, and measure outcomes rigorously. We are actively benchmarking architectures and operational metrics across sectors; if you want comparative data or a design session tailored to your estate, we would welcome a conversation.


  • Agent Workcells: Building safe, observable autonomy in enterprise environments (/insights/ai/related-topic-1/)
  • Policy-Driven AI: Designing risk-aware orchestration for regulated sectors (/insights/ai/related-topic-2/)
  • RAG That Works: Retrieval architectures for high-stakes operations (/insights/ai/related-topic-3/)

About the Research Team

The MNB Technology Research Team consists of senior architects and engineers with backgrounds spanning global banking, healthcare, retail, defence, and public sector. Our work focuses on enterprise AI, secure distributed systems, and resilient operational delivery.

Work with Us

Ready to make · new · better?

Contact us to discuss how this architecture applies to your specific environment.

Final thoughts

Enterprise technology strategies succeed when architecture, operational resilience and responsible governance are designed together. This article is intended to help readers understand how to make systems more adaptive, observable and safe.

  • Build around distributed decision logic rather than a single orchestration bottleneck.
  • Use threshold-based governance to keep autonomous actions under control.
  • Maintain modular infrastructure so models, data and services can evolve independently.