Rule automation
Known input → known route → deterministic action.Use it when the path and rules are already defined.
04 / INTELLIGENCE — GOVERNED AGENTIC SYSTEMS
SERVICE SOLUTION SHOWCASE
Governed AI Agent
Command Center
Delegate the task.
Retain the authority.
An illustrative operating model for multi-step AI work with explicit task boundaries, scoped tool access, human approval for consequential actions, observable evidence and stop conditions by design.
THE CONTROL PROBLEM
The agent can act. The business still owns the decision.
Some work changes as new information arrives: gather approved context, compare records, prepare a response, choose a permitted next step. Without a mandate, useful tool access can become unintended business authority.
Batisha Labs designs the task boundaries, approval routes and operator controls around that work—before deciding how much to delegate.
AI-assisted workflow
A bounded interpretive step inside a predefined workflow.Use AI to summarize, classify or draft without handing it the route.
Governed agentic system
Changing context + task state + permitted choices + approved tools.A system interprets a defined task, maintains relevant state and chooses among permitted steps toward an outcome, inside explicit authority and stop conditions.
Human authority
Consequential decisions remain with an authorized person.Business, commercial, legal, financial, security and production authority stay explicitly bounded.
The architecture follows the operating need. Explore AI automation · Explore digital operations
ACCESS IS NOT PERMISSION
A connected tool is not an open mandate.
Read, prepare and execute are different grants. Permission is task-specific; a tool’s technical capability is broader than the actions the business has authorized.
ACTION AUTHORITY MATRIXIllustrative classifications
External communication
Prepare a message; hold the exact recipient and payload pending authorized review.
CONTROL REQUIREMENT
Denied, expired or changed approval means no send.
Capability ≠ permission ≠ authority. Actual classifications follow the approved task, context and consequences.
Least privilege, purpose limitation and scoped capabilities shape the design. Our security approach ↗
APPROVAL BEFORE CONSEQUENCE
Prepare is
not execute.
A proposal can be complete while its execution is still held. Human approval binds the exact action—not every action that the tool could perform.
Denied or expired approval means no execution. A materially changed action requires new approval.
THE APPROVAL PACKET
Proposed effect
Exact action, target and relevant payload or parameters.
Review context
Input references, evidence, expected impact and why approval is required.
Decision boundary
Authorized approver, permitted scope and expiry or staleness condition.
Controlled consequence
Execute only the approved action; validate the result and record it.
STOP ON UNCERTAINTY
A visible stop. A useful handoff.
Missing authority, an uncertain target, conflicting instructions, stale evidence, tool failure, scope drift, approval expiry or a bounded retry/step limit stops continuation. The agent does not improvise around the boundary.
STOP → ESCALATE → HUMAN DECISION
Preserve the objective, current state, completed actions and relevant evidence. Explain the reason for stopping, the proposed next step and the decision requested from the named human owner.
External content cannot rewrite the mandate.
Treat retrieved pages, files and messages as untrusted information. Evaluate prompt injection and indirect injection, isolate secrets and check authorization at the downstream action boundary.
Failure is exposed and assigned. Roll back if required, reconcile a known state, reauthorize, then resume or close and verify. Recovery does not mean unlimited retries.
OBSERVABLE EVIDENCE
Review what happened.
Know who decided.
Record the task, input references, tools used, actions attempted, authority result, approval state, execution result, validation result, responsible operator, event times, exceptions and final state.
Accountability rests on observable events and decisions. It does not require recording private model chain-of-thought.
Keep evidence proportionate to its purpose. Read our privacy notice ↗
OPERATOR CONTROL & RECOVERY
The human is in control of continuation.
A person can pause, deny, cancel, reassign, reconcile, disable a capability or shut down the task. Controls follow the current state; the agent’s desire to continue never overrides them.
OPERATOR CONTROL VIEWConceptual operating model
TASK STATE
WAITING FOR APPROVAL
The exact consequential action is frozen pending an authorized human decision.
NEXT PERMITTED ACTIONReview the exact target, payload, evidence, scope and expiry. Approve only that action, deny it or request revision.
Explore states and human controls. No connected tools, live tasks or external effects.
TEST BEFORE MORE AUTHORITY
Evidence earns review. Review does not grant permission.
Evaluate expected behavior and failure behavior against defined conditions. Broader authority follows business need, evidence, testing, human review and explicit approval. An agent cannot grant itself more access.
- Read-only
- Recommendation
- Prepare-only
- Staging / sandbox
- Narrow reversible production
- Broader authority only after explicit approval
Some systems should remain read-only or prepare-only. The model and provider follow the requirements, tool boundaries, evidence and recovery needs.
What should scenario testing cover?
Normal and edge cases; permission denial; tool failure; ambiguous tasks; conflicting data; prompt injection and indirect injection; untrusted content; scope drift; consequential actions; approval denial and timeout; stale evidence; duplicate/idempotency behavior; rollback, recovery and regression.
Testing validates behavior against defined conditions. It does not prove absolute safety.
PROPOSED DELIVERABLES
An operating model you can build and govern.
Actual scope remains proposal-defined. Begin with the multi-step task, its owner and the consequences of getting the next step wrong.
- 01
Agent authority and tool-access matrix
Define allowed information, tools, actions, least privilege and human-only decisions.
- 02
Approval and escalation workflow
Specify exact-action approval, stops, owner decisions and controlled recovery.
- 03
Audit trail and evidence requirements
Define observable events, validation and the accepted final state.
- 04
Scenario testing and operator review criteria
Evaluate normal, exceptional and adversarial behavior before authority changes.
EVIDENCE BOUNDARY / SERVICE SOLUTION SHOWCASE
Illustrative service solution grounded in the Intelligence offering. This is not proof of a deployed external agent platform or a customer success story.
This is not a deployed customer platform, customer case study, proof of live customer usage, performance evidence or a proprietary Batisha Labs SaaS product.
START WITH YOUR OPERATING PROBLEM
Define the task before
you delegate the authority.
Bring the multi-step task, current process owner, systems involved, desired delegated actions, human-only decisions, known exceptions and desired result.
Use high-level context for the initial brief. Keep credentials, security secrets and confidential customer material out of it.
FOUR SERVICES / ONE CONNECTED PICTURE
