Enterprise AI assistants

Voice and text assistants that turn approved decisions into tracked work.

We discover, design and build assistants that connect strategic review to approved operational work over hours or days — with scoped knowledge and tools, checkpoints and people approving what matters. This page describes an engagement, not a running product or voice demo.

Discuss an assistant workflow How we bound agents

What a production assistant needs

Long-running work needs more than a chat window.

Scoped knowledge and tools: Each role sees only the approved sources and tools for its job; access is granted per deployment, not assumed.
Durable task state: Work that runs over hours or days keeps its state outside the conversation so it can survive restarts and hand-offs.
Checkpoints with pause, cancel and resume: People can inspect progress, stop a task, or resume it from the last confirmed checkpoint.
Bounded retries, idempotency, timeouts and budgets: Repeated attempts must not duplicate effects; every task has time and spend limits and escalates when they are reached.
Evidence-backed progress and escalation: Progress is reported from system evidence, and failures go to a named person with the context needed to act.
Purpose-limited audit evidence: Agreed events are recorded with minimisation or redaction and defined access and retention — not blanket raw input/output logging.

Voice is an interface

A voice is not proof of identity or authority.

Spoken or typed, a request still passes identity and access checks, and consequential actions — payments, permission or security changes, customer messages — require human approval. Leadership keeps decision accountability; the assistant prepares, tracks and reports.

Illustrative scenarios

Trigger → permitted action → approval → verified result → cost per accepted case.

Examples only — not client work, live integrations or a running demo. A model saying “done” is not completion: verified completion needs system evidence and acceptance.

Finance operations

Trigger: A controller asks, by voice or text, to work through unmatched invoice exceptions before month-end review.
Permitted action: Gather the matching records from approved read access and draft proposed matches with sources.
Approval: The controller approves or rejects each proposed match. An authorised accounts-payable specialist then records the approved match in the accounting system; the assistant makes no payment, transfer or ledger posting.
Verified result: Counted only after the accounting system shows the match recorded by that specialist and the controller's review accepts it.
Cost per accepted case: Model, review and support cost divided by accepted matches — not by attempts.

See the full role journey →

Evidence: Illustrative · reviewed 17 October 2026

Managed services / ITSM

Trigger: A service lead asks for a status brief on aging tickets for one client tenant.
Permitted action: Read tickets within that tenant only and draft a brief of ages, likely causes and suggested next steps with ticket references; a tenant mismatch stops the task. It changes no tickets.
Approval: The service lead reviews the brief and decides any follow-up; customer replies, ticket changes and security settings stay with technicians.
Verified result: Counted when the service lead accepts the brief as accurate against the referenced tickets in the ticket system.
Cost per accepted case: Total run and review cost divided by accepted, accurate briefs — not by tickets resolved.

See the full role journey →

Evidence: Illustrative · reviewed 17 October 2026

Executive operations

Trigger: An operations leader asks to turn a strategy review's decisions into tracked follow-ups across teams.
Permitted action: Draft owner-assigned tasks and a status digest from approved documents, then track progress over days.
Approval: The leader confirms each task and owner; leadership keeps decision accountability.
Verified result: Counted when the named owner acknowledges the task in the agreed system and its status reflects real updates.
Cost per accepted case: Run and support cost divided by acknowledged, accurately tracked follow-ups.

Evidence: Illustrative · reviewed 17 October 2026

Three delivery forms

Interface where it helps — none where it doesn’t.

Background automation in existing tools

An API or headless service works inside the systems people already use — a ticket queue, ledger or inbox. No new screen is a deliberate choice, not a universal goal: people still need visible approvals, progress, recovery and evidence where they already work.

Embedded conversational or task-adaptive UI

A text or voice panel, or an interface generated for the task at hand, inside an existing product. Generated views still need accessible structure, keyboard operation, clear state and a way to correct or stop the task.

A full bespoke application

Built only when the workflow needs its own records, roles and screens that configuration or integration cannot reasonably provide. Ownership, support and exit terms are agreed before build.

Whichever form fits, human-visible approval, accessibility, progress, recovery and evidence remain requirements.

Eight-step fit

Who it is for, and how we would know it helped.

Who: Leaders and process owners whose strategic decisions stall between the review meeting and operational follow-through. An audience hypothesis, not validated demand.
Change: From decisions recorded in slides to approved tasks that progress, report back and escalate over hours or days.
Promise: We scope, design and build an assistant for one bounded workflow, with agreed access and approvals. No outcome, timeline or price is guaranteed here.
Experience: Discovery → role and permission map → prototype on redacted samples → evaluated pilot → agreed operation or handover.
Proof: No client deployment of this offer is claimed. Our nine in-house showcases show engineering direction only, at their development stages.
Permission: Least-privilege access granted per role; consequential actions need identity checks and human approval.
Share: Optionally, a redacted workflow map or evaluation summary you choose to share internally.
Return: Accepted cases, review effort, cost per accepted case and reopen rate reviewed against the agreed baseline.

Finance example roles

MSP / ITSM example roles

Both are illustrative proposed journeys. The executive-operations scenario has no role journey yet.

How software is paid for

Seats, consumption, outcomes or a hybrid.

These are models in the market, not offers. We do not list service prices. Future USD proposals follow understanding your needs; scope and terms require agreement. Compare engagement options on the pricing page; no outcome-based price or guarantee is offered.

Seats: Per-user licences. Retained SaaS seats and custom systems commonly coexist; adding a custom layer does not imply cancelling them.
Consumption: Usage-based charges such as model calls or runs. Consumption measures activity, not a completed result.
Verified outcomes: A fee per accepted result. Possible only after the accepted-result definition and the safeguards below are agreed in writing.
Hybrid: A platform or fixed fee plus usage or outcome components, often with caps. Commercial fees are not the same as customer value.

Before any outcome-based contract

Accepted result: what system evidence and which reviewer confirm completion
Quality window: how long a result must hold before it counts
Reopen, retry and double-count rules
Exclusions: cases outside scope or caused by upstream systems
Attribution: what share of a result the assistant actually produced
Human review: which decisions stay with accountable people
Spend caps: maximum usage and fee per period

The illustrative scenario calculator separates cash from capacity; it is not a pricing or savings promise.

Discovery scope

What a first conversation covers.

One workflow, its trigger and the decision it should move forward.
Who requests, approves, operates and is affected.
Which systems hold the evidence of a completed result.
Whether background automation, an embedded assistant or an application fits — or none.

Send a short, non-sensitive description. Fit and any quoted scope are agreed separately; an inquiry is not a booking, and no response time is promised. Related reading: assistants that finish the work.

Next step

Describe one workflow an assistant should carry.

We reply about fit and a possible discovery scope. Do not include credentials or sensitive records.

Discuss an assistant workflow Explore our engineering work