04 / INTELLIGENCE

Governed
Agentic Systems

AI agents for complex business workflows.
Human authority over consequential actions.

Design adaptive workflows with defined mandates, controlled tool access, human approvals and explicit exception handling.

Discuss your workflow See when agents make sense

Conceptual scene / human-led AI collaboration

01 / THE OPERATIONAL PROBLEM

The request changes.
The work still needs a valid next step.

A service request can cross messages, records and internal tools. New evidence can change what is needed: ask for clarification, check an approved source, prepare a response or return a decision to its owner.

When people have to reconstruct the case at every handoff, the problem is an operating job with changing context. The first question is whether a clearer process or conventional automation can already handle it.

Clarify states and ownership with Digital Operations ↗

02 / CHOOSE THE RIGHT ARCHITECTURE

Use the least flexible architecture the job allows.

Agentic behavior becomes useful when a system must interpret an evolving situation, choose among permitted next actions, use multiple tools, and revise its path from intermediate results. If the work can follow a stable, defined route, a controlled automation may be the better system.

Defined route

Known inputs move through largely defined transitions, rules, approvals, and exception paths.

Adaptive route

The system selects among several valid steps as context changes—without leaving its authority envelope.

When does a workflow need an agent?

Compare three situations. This is an educational comparison, not a procurement diagnosis.

Selected scenario: Conventional automation

Conceptual route / Defined progressionDefined rules and exception paths
  1. Defined input
  2. Fixed route
  3. Defined rules
  4. Human approval where consequentialHuman decision
  5. Approved output

People authorize consequential output

SCENARIO / 01

Conventional automation

Operational situation
A complete request follows the same validation, routing and approval steps each time.
Relevant architecture
A controlled, rule-based workflow.
Potential capabilities
Validate known fields, route by agreed rules and execute approved transitions.
Required boundaries
Defined inputs, rules, exception paths and permissions.
Human involvement
People set the rules, approve consequential steps and own exceptions.
Important limitations
Changing conditions outside the defined paths need review or a revised workflow.
Conventional automation
Known inputs and defined routes. People set rules and own approvals and exceptions.
AI-assisted automation
Interpretation within a fixed flow. AI output is checked; assistance does not require an agent.
Governed agentic execution
Changing context and permitted choices. Bounded access, state and human authority remain essential.

Compare the situations; selection does not diagnose your workflow or recommend a purchase. Each detailed explanation is available through its selector.

03 / ILLUSTRATIVE WORKFLOW · SYNTHETIC INFORMATION

One request. Several permitted next moves.

A fictional consulting team receives a request to change a project deliverable. This is an explanation of the operating model, not a client deployment or measured result.

Conceptual business team reviewing a changing request and a human approval checkpoint
Illustrative scene / fictional workflow review, not a customer project
Illustrative stage / 01Receive the request

  1. Receive the request

    Read a synthetic change request and the approved case record. The mandate is to prepare a reviewable change brief.

  2. Choose a permitted step

    New information changes the route. Check an approved source, ask for missing details through an authorized channel, or prepare a supported recommendation.

  3. Prepare, then hold

    Draft the proposed change and its evidence. Changing the contract, promising a delivery date or accessing unrelated client records is restricted. A human must approve a consequential commitment.

  4. Stop on failed validation

    The proposed update conflicts with the current case state. Stop before committing, preserve state and record the validation failure.

  5. Escalate to the owner

    The accountable person resolves the conflict, revises the proposed action and decides whether the job should continue.

  6. Recover within approval

    Validate the correction and obtain reapproval where required. Resume only within approved limits, record the result or terminate the case.

The commercial purpose is a legible route from a changing request to an authorized outcome, with the exception and decision owner visible. Explore the illustrative governed AI agent command center to see this model in more detail.

04 / POSSIBLE ENGAGEMENT OUTPUTS

A tangible scope, agreed around the job.

Illustrative scope elements may include the following. Actual deliverables, implementation responsibilities and acceptance criteria depend on the operational problem and the agreed engagement.

Workflow map

The operational job, changing conditions, systems and accountable people.

Operating mandate

Purpose, scope, permitted inputs and actions, success, escalation and stop.

Context and tool-access design

Approved sources, provenance, working state and suitable tools.

Permission and approval boundaries

What may progress, what may be prepared and what requires a person.

Exception and recovery design

Who owns a stop, what evidence is retained and how reapproval works.

Evaluation and handoff plan

Representative cases, acceptance criteria, implementation and operating responsibilities.

These are possible outputs, not a fixed package, delivery timeline, price or guaranteed result.

Discuss the scope of your workflow ↗

002 / THE OPERATING MANDATE

An agent gets a mandate. Not a blank cheque.

“Do whatever helps” is not an operating specification. A serious agent has a defined purpose, bounded scope, permitted inputs and actions, an observable success condition, and explicit reasons to escalate or stop.

Conceptual operating mandate with a human review and approval gate before an approved action
Conceptual illustration / operating mandate and human approval
  • 01 — Purpose — The operational job the agent exists to move forward.
  • 02 — Scope — The cases, records, systems, and time horizon inside its remit.
  • 03 — Inputs — The sources it may use—and the provenance required.
  • 04 — Actions — The choices, tools, and reversible changes it may make.
  • 05 — Success — The observable state that counts as a completed job.
  • 06 — Escalation — The ambiguity, impact, or evidence gap that returns control.
  • 07 — Stop — The conditions under which continuing is not permitted.

Can the system explain what job it is doing, what it may use, what it may change, how it knows the job is complete, and when control returns to a person?

A defined mandate makes the boundaries reviewable. It does not by itself guarantee safe operation.

CONTEXT / TOOLS / STATE

Capability is assembled. Access is not assumed.

The useful agent is not the one with the most data, the most tools, or the longest memory. It is the one equipped with the right operating surface for a specific job.

Context

Approved information, with provenance and freshness appropriate to the job.

Tools

The specific tools permitted for this operation, rather than unrestricted access.

Working state

The case progress and observations that must persist within a defined scope and time horizon.

Technical access

The system can reach a tool or record. This describes capability.

Operational permission

The actions allowed by the mandate, constraints and validation rules.

Human decision authority

The accountable person who can approve a consequential action or resolve an exception.

Technical access describes what is possible. The operating mandate and human authority determine what is permitted.

004 / DECISIONS AND CONSEQUENCE

Permission is not authority.

An agent may be able to prepare an action without owning the right to commit it. Batisha Labs separates capability from consequence so low-risk work can move while consequential decisions remain visible and human-owned.

Conceptual human reviewer deciding whether to approve or reject a consequential action
Conceptual scene / approval and rejection are alternative human decisions
Human authorityCommitA person owns this decision

Explore the authority boundary at each level

01InterpretBounded agent work

01 — Interpret — Agent may — Extract meaning from permitted context.

Boundary
No unrelated sources or unrestricted memory.
Permission and human authorization
Use approved context; escalate conflicting or missing evidence.
Evidence retained
Keep source provenance and the interpretation.
02RecommendBounded agent work

02 — Recommend — Agent may — Prepare a supported next action for review.

Boundary
No commitment on the strength of a recommendation.
Permission and human authorization
Present the proposal and evidence to the responsible reviewer.
Evidence retained
Keep rationale, relevant context and the proposed next action.
03AdvanceBounded agent work

03 — Advance — Bounded — Select among approved, low-risk, reversible steps.

Boundary
No action outside the approved low-risk, reversible envelope.
Permission and human authorization
Progress only while permission, state and validation allow it.
Evidence retained
Keep the chosen step, tool, state and observed result.
04PrepareHold for approval

04 — Prepare — Approval gate — Assemble a consequential action without committing it.

Boundary
Preparation does not authorize execution.
Permission and human authorization
Hold the assembled consequential action at the human approval gate.
Evidence retained
Keep the draft action and the evidence supplied for review.
05CommitHuman authority

05 — Commit — Human authority — Approve obligations, irreversible changes, or material external effects.

Boundary
The agent cannot grant itself authority to commit.
Permission and human authorization
A person explicitly approves the obligation or material external effect before authorized execution.
Evidence retained
Keep the approver, decision, scope and execution result.
06Override / stopHuman authority

06 — Override / stop — Human authority — Interrupt the system and resolve an exception.

Boundary
No self-approved recovery or bypass of required reapproval.
Permission and human authorization
A person may interrupt, resolve, revise, authorize a retry or terminate.
Evidence retained
Keep the stop reason, preserved state and recovery or closure decision.

Allow the agent to interpret and advance bounded work. Require human review when ambiguity rises. Reserve commitments, irreversible actions, and material external effects for explicit authority.

Illustrative approval journey: Interpret the approved request → recommend a supported next step → advance permitted reversible checks → prepare the change → hold for the accountable person → execute only as authorized → retain evidence. A rejection or unresolved exception stops progress.

STOP / ESCALATE / RECOVER

A governed system knows when not to continue.

Stopping is not a failure of intelligence. It is a designed response to missing evidence, conflicting state, insufficient confidence, denied authority, tool failure, or a step whose consequence belongs to a person.

Conceptual stop and escalation path with human-owned resolution, validation and required reapproval before recovery
Conceptual illustration / stop, human resolution and controlled recovery
  • INCOMPLETE — Required information is missing or cannot be verified.
  • CONFLICT — Sources, instructions, or system state disagree.
  • UNCERTAIN — Confidence is insufficient for the permitted next action.
  • DENIED — A tool or record falls outside current permission.
  • FAILED — A tool call, write, or validation did not complete as expected.
  • CONSEQUENTIAL — The next step carries authority reserved for a person.

When a stop condition occurs, the system preserves working state and supporting evidence, routes the exception to a human owner, and waits for a decision to resolve, revise, retry, or close the job.

Explore a conceptual recovery stage

Stop

Do not continue after missing evidence, denied authority or failed validation.

Actions outside the mandate must also stop. Recovery never bypasses a required approval gate.

006 / TRACEABILITY AND EVALUATION

The system should show its work.

A real agentic system is operated, reviewed, and improved. Meaningful actions should leave enough evidence to understand the state used, the tool called, the decision made, the authority applied, the result observed, and the exception raised.

Conceptual people reviewing documents, approval evidence and pass, hold or exception states
Conceptual evidence review / abstract states, not customer performance data

Illustrative evidence labels

Conceptual examples of what a trace may describe. These are synthetic labels, not live system activity or evaluation results.

Approved case record · source fresh

Research branch · mandate match

Approved search · 3 sources retained

External commitment · human approval required

Conceptual evidence path / not live activity

  1. Source
  2. State
  3. Decision
  4. Authority
  5. Observed resultPass
  6. Exception

Illustrative valid path: the evidence supports the permitted next step. A consequential action still requires human authority.

Behavior

Does the agent select a valid path for representative and difficult cases?

Boundaries

Does it refuse, stop, or escalate when context, permission, or authority is insufficient?

Recovery

Do failed tools and unexpected states become visible, owned exceptions?

Regression

Do system changes preserve the behaviors and controls the operation depends on?

Representative evaluation should include permitted actions, restricted actions, approval enforcement, missing information, failed tools or validation, escalation, recovery, termination and regression after changes. Evaluation does not promise zero failures.

Read about automation, AI and human authority ↗

007 / HOW BATISHA LABS ARCHITECTS THE SYSTEM

From operational job to governed capability.

The architecture begins with the work and its authority model. Models and frameworks enter only after the mandate, context, tools, state, consequences, exceptions, and evidence can support a serious system decision.

  • 01 — Define — Name the job, the outcome, and the operating mandate.
  • 02 — Constrain — Set context, tools, state, permissions, and consequence levels.
  • 03 — Design — Model valid choices, observations, approvals, exceptions, and recovery.
  • 04 — Implement — Connect the smallest complete agentic operating loop.
  • 05 — Evaluate — Test behavior, tool use, boundaries, failure modes, and regressions.
  • 06 — Operate — Expose traces, review exceptions, and improve the governed system.

A system that can adapt its next step without becoming an uncontrolled black box: bounded in authority, visible in action, prepared to stop, and designed for human operation.

Agree which stages belong in the engagement and who owns monitoring, maintenance and review. Ongoing managed operation is not automatically included.

Explore how we work ↗

A SUITABLE ENGAGEMENT

Bring a job whose next step depends on what happens next.

You do not need to arrive with an agent framework, model, memory architecture, or tool stack selected. You need a real multi-step operation, meaningful variability, and a clear reason to improve how the work moves.

  • Context changes the route — The next valid step depends on intermediate results, not one fixed path.
  • The job crosses tools — Useful progress requires controlled reading, analysis, and action across approved systems.
  • Working state matters — A multi-step case must retain task state while the situation evolves.
  • Authority can be named — The business can distinguish permitted progress from decisions that require a person.

Poor starting points

“Give AI access to everything,” replace accountability with autonomy, add agents to a job with no operating model, or choose an agentic architecture where a simpler controlled workflow would do.

Compare all four service layers ↗

START A PROJECT

START WITH THE JOB AND ITS AUTHORITY

Bring the operation that cannot be reduced to one fixed path.

Describe the job, the context that changes, the systems it must use, the state it must carry, and the decisions that remain human. The project brief will help make the real operating boundary visible.

01 The multi-step operational job

02 Why the next valid step changes

03 The systems, tools, and state involved

04 The actions that require human authority

A written brief starts the discussion. We clarify the job and its boundaries, assess whether the architecture fits, then agree any proposed scope before implementation.

Discuss your workflow