The runtime that takes an agent from a demo to a governed production asset.
Most agent platforms stop at "you can build it". This one is organised around the full lifecycle — strategy, capability, evaluation, release, observation and optimisation — because that is the only shape in which an estate of agents survives contact with the business. This page is the overview for the technical and platform teams who will own it.
Six architectures
Chat, Chat Flow, ReAct, ReWoo, Deep Research, and registration of agents built elsewhere
One lifecycle
Six closed-loop stages from strategy development to quality optimisation
Evaluation first
Test sets, four assessor types, regression runs and visual reports — not an afterthought
Systems integration
MCP both directions, A2A, and read/write access to your systems of record
Six agent architectures. Picking the wrong one is the most expensive mistake you will make.
An agent's architecture is not an implementation detail. It determines whether the agent asks or acts, whether it plans before it acts, how many tools it can safely hold in mind at once, and what your evaluation set has to look like. Choose deliberately, per use case — not once for the whole estate.
| Architecture | What it does | Where it fits | Key configuration |
|---|---|---|---|
| Conversational Conversational (对话型) |
Sustained multi-turn question and answer. The agent responds; it does not act on its own. | FAQ assistants, onboarding helpdesk, internal policy questions — anywhere the answer is the deliverable. | System prompt, knowledge bindings, response format, session and memory scope. |
| Conversational Flow Conversational Flow (对话流型, Beta) |
Conversation fused with an orchestrated flow — the dialogue follows a designed path rather than free-form branching. | Guided service journeys, scripted qualification, front-desk conversations with a fixed compliance spine. | Flow definition, node sequence, branch conditions, handoff points. |
| Think–Act (ReAct) | Interleaves reasoning and tool use: think, call a tool, read the result, think again. Planning is free-form. | Few tools, flexible process, real-time feedback, complex planning not required. The workhorse for operations tasks. | Tool set, iteration limit, planning requirement, reply requirement, model tier. |
| Plan–Act (ReWoo) | Produces an execution plan first, then works through it. Supports an explicitly guided reasoning chain. | Many tools working together, a clear goal, and a high requirement for process completeness and auditability. | Tool set, planning requirement, guided Chain-of-Thought, reply requirement, verification step. |
| Deep Research | Long-horizon execution that keeps the think–act alternation, extended through Skills for reusable capability. | Literature and report scanning, competitive intelligence, multi-source synthesis — long chains with reusable steps. | Skills library, iteration budget, source and citation policy, stopping condition. |
| External agent registration | Agents built on other platforms — third-party low-code, or your own engineering team — are registered into one governed entry point. | Organisations that already invested in agent assets elsewhere and refuse to start again. | A2A protocol or SSE conversational interface, identity mapping, permission scope, routing rules. |
Two modes, one switch. Every prompt configuration can toggle between single-agent and multi-agent orchestration, and the reasoning mode can be set to ReAct (free tool calling) or Plan-and-Execute (emit a plan, then execute it item by item), with an iteration parameter bounding the maximum thinking rounds. When a simple intent arrives, you do not pay for a planning loop — when a complex one does, you get one.
Register, do not replace
The most expensive word in agent programmes is "rip and replace". Registering agents you already built — over A2A, or over SSE for conversational ones — means an existing estate becomes governable on day one instead of after a rebuild.
Architecture is a business decision
A ReAct agent that improvises is right for troubleshooting and wrong for anything that must be defensible. We make that choice with you explicitly, per use case, and write down why.
Fast paths stay cheap
Built-in intents take the fast path; complex intents take the reasoning path. This dual approach exists because "slow and expensive for everything" is how you lose a budget owner in week six.
The platform in numbers
Chat · Chat Flow · ReAct · ReWoo · Deep Research · external
Strategy → capability → evaluation → release → observation → optimisation
Including model-as-judge, with a stated boundary each
Not sampled — evaluation sees everything
Six agent architectures
Picking the wrong architecture is the most expensive mistake in this list, because it is invisible until month three. Match the architecture to how the work actually behaves — not to how sophisticated it sounds.
| Architecture | How it works | Use it when | Do not use it when |
|---|---|---|---|
| Chat | Single agent, conversational, with tools and memory | Advisory work with a human in the loop on every turn | The task needs to run to completion unattended |
| Chat Flow | A fixed, designed sequence of steps with branching | The process is documented and the sequence is stable | The path genuinely varies case by case |
| ReAct | Reason and act in a loop — think, use a tool, observe, repeat | The path cannot be written down in advance but the goal is | You need a guaranteed, bounded number of steps |
| ReWoo | Planned multi-agent: one planner, several specialists | The work splits cleanly across distinct expertise | The split is an artefact of your org chart, not the work |
| Deep Research | Long-running investigation with iterative search and synthesis | Genuine research where the source set is not known upfront | There is an authoritative internal source you should just read |
| Register external | Bring an agent you already built | You have working assets and want governance and evaluation applied | You have not yet proven the workflow deserves an agent |
Every enterprise ends up with agents that cannot talk to each other, or to anyone.
The platform is organised as a digital employee management hub: one unified interaction entry point, N general-purpose agents ready to use, and X business agents you build and operate yourself. It exists to answer a specific organisational failure — agents becoming the next generation of digital islands.
One unified entry point
A generative canvas: one natural-language instruction produces a personalised workspace view, card-based and different for each person. People stop navigating a menu of bots and start stating intent in one surface that routes to the right agent.
General-purpose agents
Ready-to-use agents for the things every enterprise needs first — search across company knowledge, document drafting, research, data query, onboarding. They carry value before a single bespoke agent is built, which is how you buy time for the bespoke work.
Business agents, built and operated by you
The long tail: claims triage, credit assessment, compliance review, plant inspection. These are yours, they encode your judgement, and they are governed, evaluated and versioned on the same platform as everything else.
The pain point nobody budgets for
Large enterprises now run hundreds of agents in production. Each was built by a different team, for a different sponsor, against a different assumption about what a "customer" or a "case" is. Two agents answer the same question differently and both are "correct". Nobody can say which is authoritative. When budget is cut, the agents without an owner are switched off first — and the ones with an owner are rarely the ones doing the most work.
That is not a tooling failure. It is what happens when capability is added without a management layer. The 1 + N + X model is that layer: one entry point so people do not have to know the org chart, general agents so you are not duplicating commodity capability, and a governed estate for everything specific.
The test we apply before go-live. For any agent you propose to deploy: who owns it, what happens when it is wrong, which other agent contradicts it, and what evidence you would show an auditor. If four of those five answers are unclear, the agent is not ready — regardless of how well it works in a demo.
Why the number of agents is the wrong metric
| Failure mode | What it actually costs you |
|---|---|
| Duplicated capability | Four document-drafting agents, four maintenance streams, no single improvement. |
| Contradictory answers | The user picks the one they believe. Trust in the platform drops quietly, not loudly. |
| Unowned agents | Deactivated in the first budget review, along with work that quietly moved back to humans. |
| No shared semantics | Every integration is a one-off mapping. Integration cost grows with every new agent. |
| No evaluation baseline | A model or prompt change is rolled out on hope, and nobody can prove it was an improvement. |
An estate of a dozen agents with shared semantics, shared ownership and a regression set is a manageable estate. A handful built on conflicting assumptions is not — and no tooling decision will fix it.
Six stages, one closed loop
The loop is the point. Most platforms give you stages 4 to 6 and leave you to invent 1 to 3, which is why most agent estates cannot be trusted.
Which workflows should be delegated at all, and which should explicitly not be. This stage has killed more projects than any technical decision.
Tools, knowledge, permissions and escalation. What the agent may reach, and what it may not.
The test set is built from your historical cases before the agent is built, not after it fails.
Who approves, at what frequency, and what gets logged. The named human is agreed before go-live.
Every conversation scanned. Cost, latency, override rate, and the failures you did not anticipate.
The loop closes: observed failures become new test cases, and the harness gets stricter.
Give every agent a department, a job, an accountability and a KPI.
This is the single capability that distinguishes an agent platform from an agent framework. If your agents are not managed like people, you will spend the rest of the programme arguing about trust instead of about output.
On the Agent Platform, an agent is an organisational unit. It belongs to a department. It holds a position with defined responsibilities. It has permissions that are granted, reviewed and revoked — and it is measured against expectations that somebody owns.
The decisive detail is that it uses the same RBAC model as your human staff. One permission system, one identity model, one audit trail. An agent that needs read access to a customer record has that access granted in the same system, by the same process, as a person who needs it — which means your access reviews suddenly cover agents without a single extra meeting.
- Onboarding and offboarding at scale. Agents can be onboarded, moved and decommissioned in batches, with permissions reclaimed at the same time. Leaving the agent switched off but still holding read access to finance data is a finding waiting to happen.
- Authority is explicit and bounded. The tools an agent may call and the knowledge it may query are configured by administrators, so an agent cannot reach a system its operator never granted it.
- Change is logged. Every permission change and administrative action is retained. Anomalies — changing permissions outside working hours, bulk grants — can be flagged.
- Least privilege is the default we configure. For a standard member, data export and credential management are typically removed. We set this during deployment, because it is rarely on by default and always needed later.
An agent's personnel record
What you should be able to answer about any agent in production, without opening a code repository.
| Attribute | Why it matters |
|---|---|
| Owning department | Who has the authority to switch it off? |
| Role and responsibilities | What is it accountable for, in business terms? |
| Scope of data access | Which systems may it read, and which may it write? |
| Tools it may call | Does it move money, send email, or write to a system of record? |
| Performance measure | The metric that says whether it is doing its job. |
| Escalation path | Where does the work go when confidence is too low? |
| Review date | When someone last confirmed it should still exist in this form. |
If your current estate cannot answer these for every agent, that gap — not the model, not the retrieval strategy — is the work programme.
Where this connects to the rest of our business. This is the operational expression of Human Machine Capital: people and agents treated as the same class of operating asset, built, measured, governed and retired on the same discipline. It is also why our learning practice exists — an organisation cannot run digital employees it has not taught its people to work alongside.
Give every agent a department, a job and a KPI
An agent with no named owner is a liability nobody can escalate to. This is the RACI we insist on before go-live — and it is the same discipline you would apply to a new hire.
| Task | R | A | C | I |
|---|---|---|---|---|
| Define what the agent may do | Workflow owner | Function head | Risk, legal | Technology |
| Build and version the agent | Engineering | Technology lead | Workflow owner | Risk |
| Approve the evaluation threshold | Evaluation lead | Risk function | Workflow owner | Technology |
| Supervise live decisions | Operations supervisor | Operations manager | Workflow owner | All |
| Train the operators | Learning and L&D | CHRO or function head | Operations | Risk |
| Approve a version change | Engineering | Technology lead | Evaluation lead | Operations |
| Retire the agent | Workflow owner | Function head | Risk | All |
Six stages, one closed loop
The loop is deliberately biased towards business operation rather than infrastructure operation. Dev/Test/Ops matters, but the failure mode in most estates is a deployed agent nobody reviews and nobody can improve.
Strategy development
Which processes get an agent, what authority it holds, what it must never do, and how it will be measured. Done badly, everything downstream is wasted.
Capability building
Architecture, prompt, knowledge, tools, integration, access. Includes building at whatever level of code the problem requires.
Effect evaluation
A test set that represents your business, an assessor suited to each question type, and a baseline you can compare every later change against.
Application release
Channels, SDK embedding, REST API with streaming output, MCP server publication, and — importantly — a controlled rollout rather than a switch-on.
Production observation
Full-chain tracing, metric monitoring, conversation quality scanning, bad-case collection, user feedback and cost attribution.
Quality optimisation
Production data becomes evaluation data, which becomes a better prompt or a tuned model. This is where an agent gets better instead of older.
Low code, high code, no code — mixed by default
The realistic answer to "how should we build this" is "differently, every time". Business teams build prototypes from prompts, knowledge and flows. Developers build custom interfaces, intent recognition, retrieval operators and recall strategy, high-availability architecture and bespoke tools.
Low-code components are designed to be consumed by high-code engineering — through SDKs and APIs, not screenshots and re-implementations. And there is a full code entry point for creating agents in bulk when you need to provision hundreds of them programmatically. Teams that insist on one mode end up either blocked by the platform's edges or maintaining a shadow system beside it.
When to go past the visual builder
- Retrieval strategy is the product. If answer quality depends on a custom chunking, recall or reranking behaviour, own it in code.
- The interface matters more than the answer. Some agents exist inside a transaction screen; build that surface properly.
- Provisioning is the work. Creating agents one at a time by hand does not scale past a certain estate size.
- Nobody should be reverse-engineering a prompt. Anything you cannot read in a versioned, reviewable form is not production engineering.
Where enterprises actually deploy agents
Twenty-plus recurring patterns. The variation between them is rarely the model — it is which architecture you choose, which knowledge you mount, and where the human handoff sits.
Customer service
Common questions, product recommendation, order tracking, complaint handling. Pre-sales needs technique; post-sales needs throughput. Two different agents.
Internal knowledge assistant
Onboarding, operations troubleshooting, and natural-language queries over business data. The highest-volume, lowest-risk starting point in almost every estate.
HR assistant
Recruitment screening, attendance, leave, employee queries, profile assembly. Transactional, high volume, easy to measure.
Office automation
Meeting records, minute assembly, contract clause review, travel, scheduling. Usually the first thing an enterprise builds and the first thing they under-build.
Marketing and content
Asset generation, selling-point extraction, audience matching. Also the home of content-insight agents that coordinate analyst, retrieval and reporting sub-agents.
Sales role-play
Simulated customer interaction for conversation training and scenario practice. Pairs naturally with our learning practice — the agent teaches, the curriculum tracks it.
Data analysis agent
Natural-language queries over the warehouse: conversational reporting on operational metrics, visual charts, attribution analysis and anomaly alerting.
Deep research
Locating specific information inside large volumes of reports, producing professional research output with charts. The architecture that most obviously needs Skills.
Process automation
Ticket classification and routing, order synchronisation across systems, financial close, approval chains. Where integration earns back its cost immediately.
Equipment maintenance
Manufacturing maintenance, industrial control queries, long-running inspection routines. Often the clearest case for private deployment and local models.
Engineering productivity
Requirements consolidation, assisted coding, code review, quality checks, release verification, effectiveness measurement — across the whole demand-to-release chain.
Supply chain & finance
Inventory management and automated reconciliation. Reconciliation is the ideal first automation: high volume, clear rules, unambiguous success criteria.
Compliance & legal
Always-on compliance questions, contract clause review, code review, quality inspection. Requires citations — an unsourced compliance answer is worse than none.
Security operations
Round-the-clock threat assessment, automated handling of the full alert volume, and surfacing attacks that were deliberately hidden.
Credit assessment
Lending approval as an explicit industry pattern. The archetype for Plan-and-Execute with a human breakpoint before the irreversible step.
Public sector administration
One-stop services and long administrative approval chains handed off between steps. Sovereignty requirements usually decide the deployment topology.
Public opinion insight
Real-time market reading with risk and opportunity alerting — and the chain from insight through to sales enablement and contract review, which is where it pays.
Financial advisory
Fund manager performance analysis and allocation support for advisers and retail investors. Advice-adjacent, so suitability boundaries and review trails are non-negotiable.
Education
Learning companions, campus information service, syllabus design and schedule push. Our learning business means we build these against real curricula.
Healthcare
Guided triage from patient history and symptoms, virtual health assistants, record assembly. Deployment and audit requirements dominate the design.
Multi-market expansion
Multi-language companions, cross-language consistency review of multinational contracts, document translation pipelines. Consistency across languages is the hard part, not translation.
Sales operations
Target decomposition, business diagnosis reports, multi-platform commerce consolidation where every system exports a different header format.
Compliance review at scale
Expense pre-review, resume assessment, organisational diagnostics. Each an ordinary agent with an unusually high false-negative cost.
Knowledge and document work
Policy interpretation, risk identification, material preparation and document review — usually the first workloads enterprises hand to a governed team agent.
Where enterprises actually deploy agents
Read the last row first — that is where we would start. Everything above it tells you whether that starting point is realistic.
| Contact centre | Claims | Order to cash | KYC / onboarding | Compliance review | IT service desk | Field service | |
|---|---|---|---|---|---|---|---|
| Workflow documentation | |||||||
| Data readiness | |||||||
| Regulatory intensity | |||||||
| Human fallback needed | |||||||
| Volume of value at stake | |||||||
| Our recommended first step |
Five questions that settle whether you need this
Five yes-or-no answers. If you cannot answer the first three, the capability is not your bottleneck yet.
- Can you name the specific workflow this serves — not the department?
- Can you name the person accountable when it is wrong?
- Can you show me historical cases where a human did this task, so we can build an evaluation set?
- Can you tell me what this capability explicitly will not do?
- Can you tell me what it costs per task, and how you would reduce that cost?
What we do not claim this platform does
We went through the product documentation line by line. Some things enterprises assume exist do not have a documented, productised mechanism. We would rather you hear it here than discover it in week two of a rollout.
No documented knowledge expiry or version rollback
There is no productised TTL, no automatic document retirement, and no knowledge versioning mechanism in the documentation. And while canary release is supported, there is no documented customer-facing version rollback. What we do instead: document lifecycle is handled as an operating procedure — ownership per knowledge base, a review cadence, re-ingestion triggered manually after edits, and environment promotion through DSL metadata import and export. It works, but it is process, not product, and we will scope it as such.
No documented per-channel rate-limiting console
There is no published configuration interface for published-channel rate limits or quotas. Quota and warning thresholds exist at the account and sub-account level, and cost is a first-class dimension in evaluation — but the fine-grained throttle is not something we will describe as a feature. What we do instead: capacity planning at the topology level, plus application-side rate discipline at the integration layer, designed with your architects.
No documented model allow-list or deny-list interface
Models and agents are authorised separately and model quotas can be enforced, which covers most governance requirements. A fine-grained model allow-list or deny-list screen is not something we found documented. What we do instead: model access is designed into the deployment — which roles can reach which model tier, pinned versions in production, and change control over upgrades.
Some capability we will confirm before you rely on it
Scanned-document OCR support is described inconsistently across the vendor's own community material — one note says editable text formats only, another describes automatic OCR recognition. Rather than pick whichever sounds better, we will run your own sample documents through it during a technical workshop and let the results decide. Plugin catalogue completeness is similar: we hold a verified subset, not an exhaustive export.
And the limits of this page. Market figures for plugin counts, concurrent agent numbers, availability percentages and cluster sizing differ between vendor materials and third-party reporting. We have deliberately left all of them out. If a number matters to your decision — throughput, concurrency, contract terms — ask us for it in writing and we will get you a sourced answer or tell you it is not available.
Questions we get asked first
We do not ask you to replace it. The platform sits above your models and your systems of record; if you have working assets, we register them and apply evaluation and governance to them. Replacing a runtime is rarely the bottleneck.
Yes. Model choice is a routing and cost decision, not a platform commitment. We will tell you honestly where a cheaper model is sufficient.
Typically a small number of agents each with a named owner, a scope boundary, an evaluation threshold and a decision log. Not hundreds of unowned assistants.
Your team, from week five. Our commitment is that you can operate it without us — if we cannot achieve that, we have built something you are locked into, which is not a good outcome for either side.
What this platform does not claim
This platform does not make your organisation agentic. It will not tell you which workflows to delegate — that is a consulting judgement and it is the expensive part. It does not remove the need for trained operators, and it does not replace your governance function. Anyone who tells you a platform does all of that is selling you a procurement decision instead of a capability.
When this capability is the wrong answer
We would rather disqualify the work than take it and under-deliver. These six mean stop and fix something else first.
- The workflow it would serve is not written down as policy — fix the process first.
- There is no named human who would be accountable if the agent got it wrong.
- You have no historical cases to build an evaluation set from.
- The data it needs does not exist in a governed, readable form yet.
- Someone is asking for it because a competitor announced it.
- The business case rests entirely on headcount reduction in a function you cannot actually resize.
What the first ninety days look like
The same shape on every capability. The content differs; the checkpoints do not.
| By day 30 | By day 60 | By day 90 |
|---|---|---|
| Baseline captured on your metric | Workflow running with a named approver | Metric moved, against the baseline you did not choose |
| Scope boundary documented — including what it may not do | Evaluation harness re-running on every change | Decision log reviewed by your risk function |
| Historical cases assembled for testing | Training delivered, completion in the LMS | Next workflow scoped from what we learned |
| Data lineage for every source the agent reads | Cost per task measured and modelled | Evidence pack complete and accepted |
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring one process. We will show you which architecture it actually needs.
A working session using your own process, your own documents and your own access model. You will leave with an architecture recommendation, an evaluation-set outline, and an honest view of what this platform will not do for you.