Lowest autonomy
Automation
The system runs a fixed path
- Use when
- The steps are known, repeatable, and rule-based.
- Control
- Exceptions stop the run and go to a person.
- Example
- Extract fields from an inbound document and create the record.
Build · Agents & Copilots
Give teams focused AI assistance inside defined workflows.
Scoped assistants for specific roles and tasks, with defined permissions, defined actions, defined limits, and a person accountable for what ships.
Use the least autonomous design that achieves the outcome reliably. Read left to right; move right only when the pattern to the left cannot do the job.
Medium autonomy
Copilot
A person stays in the driving seat
- Use when
- Judgement is needed, but drafting or searching is slow.
- Control
- Nothing is sent or saved until the person accepts it.
- Example
- Draft a reply from approved sources for the handler to edit and send.
Highest autonomy — use last
Agent
The system plans steps inside a fixed boundary
- Use when
- The path varies, but the tools, scope, and stop rules are fixed.
- Control
- Bounded tools, reversible actions, logged runs, human sign-off at the edge.
- Example
- Gather case context across approved systems and prepare a reviewed brief.
Inside the boundary
- A named workflow with a defined start and finish
- A fixed set of tools and system actions it may call
- Read access limited to approved sources and the user's permissions
- Reversible steps only, with drafts instead of sends
- Every action logged with inputs, outputs, and the account used
Handed to a person
- Anything outside the defined scope
- Irreversible or externally visible actions
- Low-confidence or unsupported answers
- Commercial, legal, clinical, or safety judgement
- Repeated failure, which stops the run
Choosing the pattern
Copilot, agent, or automation
Copilot
Assists a person inside a task. The person stays in the flow, sees the suggestion, and decides what happens next. Nothing leaves the screen without them.
Agent
Performs a bounded sequence using approved tools and permissions. The boundary, the tools, the stopping conditions, and the review points are defined before it runs.
Automation
Deterministic rules and integrations. No model judgement involved — the right answer when the logic is knowable and stable.
Use the least autonomous design that achieves the outcome reliably.
Implementation blueprint
How this is actually built and run
01 · Trigger
A person opens the task, or a defined event starts a bounded sequence within agreed operating hours and scope.
02 · Context and data
Approved sources and tools only, with permissions inherited from the user. The tool list is explicit — anything not listed cannot be called.
03 · AI task
Suggest, draft, retrieve, or execute a defined sequence of steps, stopping at the agreed boundary or when confidence drops.
04 · Human control
Copilot output is always reviewed in place. Agent sequences stop at defined checkpoints, and any external or irreversible action requires approval.
05 · System action
Writes back to the approved system, opens a draft, or hands a completed step to a person with the working shown.
06 · Evaluation
Scenario tests across expected and edge paths, including refusal cases, tool failures, and the stop conditions themselves.
07 · Monitoring
Every tool call logged, with completion, escalation, and override rates reviewed on a schedule.
08 · Ownership
A named business owner, plus a technical owner for tool permissions and scope changes.
The problem
What this solves
General-purpose chat tools get used informally, without permissions, evaluation, or records. That produces inconsistent quality and unclear data exposure. A useful assistant is narrow: one role, a defined task set, and explicit boundaries on what it can touch.
When this solution fits
- Teams repeat the same research, drafting, or lookup work daily
- Staff are already pasting company information into consumer AI tools
- You want assistance without unsupervised autonomy
- A role has a well-defined task set and a clear quality standard
- Quality needs to be consistent across a team, not per-person
Example workflow
A pre-meeting briefing assistant for a client-facing team
01
Trigger
A meeting is booked in the calendar with a linked CRM account.
02
Gather
The assistant pulls account history, open items, and approved reference material within the user's permissions.
03
Draft
A structured brief is produced against a fixed template, with sources cited.
04
Review
The owner reads, edits, and decides what to use. Nothing is sent externally by the assistant.
05
Log
The final brief and the edits made are logged for quality review and improvement.
What is implemented
- Role and task scoping with the team that will use the assistant
- System prompt, tool set, and action boundaries
- Permission model aligned to existing identity and access controls
- Retrieval over approved sources only
- Evaluation set and pre-release testing against known cases
- Monitoring, feedback capture, and escalation to a person
Systems and data inputs
- Approved knowledge sources and templates
- CRM, service desk, calendar, or document systems as required
- Identity provider for role and permission mapping
- Representative examples of good and unacceptable outputs
Human control
How oversight is designed in
- The assistant proposes; the user decides and owns the output
- External-facing actions require explicit human confirmation
- Tool access is allow-listed, not open-ended
- Permissions inherit from the user, so it cannot surface data they may not see
- Users can flag a bad output in one click, and flags feed the review cycle
Tangible outputs
- A deployed assistant inside the tools the team already uses
- Documented scope, capabilities, and limits
- Evaluation results from pre-release testing
- Usage and feedback reporting
Measurement model
How we know it is working
| Measure | How it is tracked |
|---|---|
| Task completion time | Before and after, for the specific tasks in scope |
| Acceptance rate | Share of outputs used with minor or no edits |
| Edit distance | How much users change before using the output |
| Flagged output rate | User-reported quality issues per period |
| Active usage | Weekly active users against the intended population |
Boundaries
What this solution does not promise
- We do not deploy assistants that take consequential actions without human approval
- We do not promise the assistant will always be correct; review remains required
- Scope is deliberately narrow — a scoped assistant is not a general workforce replacement
- Model behaviour can change with vendor updates; that is why evaluation runs continuously
What to expect from AI: AI outputs can be incomplete or wrong. NeuronFlow designs appropriate review, access, testing, monitoring, and escalation into each solution. Capabilities and controls depend on the use case, data, systems, and approved scope.
Related solutions
Knowledge Systems
Make your documented knowledge findable and usable, with answers grounded in approved sources and traceable back to them.
Explore →
Workflow Automation
Redesign and automate high-volume business processes end to end, with humans kept in the loop where judgement matters.
Explore →
Training & Adoption
Adoption programmes built around real tasks, so capability stays inside your organisation after launch.
Explore →
Find the AI opportunities worth implementing in your business.
Start with a structured assessment of your workflows, systems, and data, and leave with a prioritized view of where AI can create real value.