AI agents with a defined job and a human owner.
Give the system a useful assignment. Decide what it may do, when it must stop, and who takes over.
Soxoa scopes agentic AI consulting and implementation around one real workflow. We compare simpler options, test the permissions and failure cases, and plan ownership before putting an agent into operation.
- Assignment
- Prepare an inbound service request for review.
- Permitted reads
- The request and approved service records.
- Proposed output
- A suggested route and a reply draft with sources.
- Approval boundary
- A person approves the send. Missing authority stops the action.
Illustrative design. Actual access and approvals are agreed and tested for the workflow.
Choose the least autonomy the job needs.
“Agent” is used broadly. The useful buying question is which decisions the model makes and which remain fixed.
| Approach | How it behaves | When to consider it |
|---|---|---|
| Deterministic automation | Rules specify the steps and decisions. The same conditions follow the same path. | Known triggers and clear rules: copy an approved field, check a required value, or send a scheduled reminder. |
| Model-guided workflow | The sequence stays fixed; a model interprets text or drafts an output at defined steps. | Variable inputs with a known process: classify an email, extract proposed fields, then put the result in a review queue. |
| Bounded AI agent | A model chooses its next step or tool within an explicitly limited assignment. | The next useful lookup depends on what the previous one found. The extra flexibility must earn its cost and review effort. |
This distinction follows Anthropic’s engineering guide to workflows and agents. Start simple; add model-directed steps only when testing supports the extra complexity.
A service request, prepared for a person.
An illustrative pilot. No client result or measured performance implied.
A request arrives with an incomplete description. The system reads permitted service information, identifies what is missing, and prepares a suggested team assignment and reply. If another approved lookup is needed, a bounded agent may choose it. If the path is always the same, a fixed workflow may suffice.
The reviewer sees the source records and unresolved questions beside the draft. Sending requires their approval. A request involving an unknown customer, conflicting records or unavailable access goes to manual handling. The test includes a repeated request and a failed lookup so the system cannot quietly turn one job into duplicate work.
The boundaries belong in the build.
Make the job ready
Name the workflow owner, approved sources, expected result and unacceptable mistakes. Bring representative samples and a manual baseline. If the process or source records are unreliable, fix those before adding autonomy.
Limit permissions in the system
Start with permitted reads and draft outputs. Enforce access and approval checks in the application and connected tools; instructions to the model are insufficient. Unapproved writes and sends stay blocked. Treat instructions inside incoming documents as untrusted content.
Give every run a stopping point
Set limits on time, tool calls and spend. Define which failures may retry and how duplicates are detected. Before repeating an action, check whether it already happened. A timeout or uncertain result goes to the named escalation path.
Test the failures as well as the happy path
Agree on pass criteria before running approved, redacted or synthetic cases. Include missing records, conflicting sources, denied access, duplicate requests and instructions that try to bypass approval. Check the resulting records and actions, not only the agent’s explanation.
Make intervention ordinary
Record permitted inputs, tool actions, approvals, errors and version details without collecting unnecessary sensitive data. Assign log access and retention. The owner needs a review queue, a way to stop the system and a documented manual fallback.
Hand over the evidence and the controls.
The handoff should include the workflow and permission map, versions, test cases and failures, approval rules, operating limits, logs, escalation instructions and a named owner. Rerun the agreed checks when models, tools or business rules change.
An AI Build Sprint can fit a bounded implementation. Hosting is a separate choice: use the private and local AI guide to decide where the data may go. A useful evaluation may end with simpler automation or a written stop recommendation.
Read before granting access.
Questions before the first pilot.
Based in Sacramento. Working with teams across Northern California and the Bay Area.
Does our business need an AI agent?
Only if the job needs the flexibility. When the steps and decisions are known, rules or a model inside a fixed workflow may be easier to test and operate. Compare those options on approved examples before buying an agent platform.
Can an agent send messages or update our systems?
Tools can enable those actions, but permission must be explicitly scoped. For a first pilot, permitted reads and drafts may be enough. Any write or send needs an agreed authority path, application checks, failure handling and tests before it is enabled.
Does agentic AI require a cloud model?
No. Hosting and autonomy are separate decisions. An agent can use a local, self-hosted or hosted model where its capabilities fit the job. Its tools, document processing and logs still need a data-flow review; local hosting alone does not establish privacy.
What can a Soxoa engagement deliver?
A scoped evaluation or AI Build Sprint can cover the workflow, permission map, acceptance cases, implementation and operating handoff. A failed evaluation can produce a narrower recommendation or a stop decision. Scope and price are agreed before work begins.
Bring one job and its limits.
Describe the recurring work, the systems it touches and the decision a person must own. We will discuss whether an agent adds something useful and what the first test would need to prove.