A useful agent needs a narrow job and a clear action boundary
An illustrative onboarding pipeline shows where model judgement helps—and where ordinary software should decide.
“Give an agent access to our systems and let it help” is an incomplete brief. Before connecting tools, I want a specific job, a permitted action set and a visible definition of completion. A narrower starting point makes it easier to evaluate whether autonomy adds value.
A concrete onboarding example
Consider an illustrative employee-onboarding assistant. Its job is to prepare a checklist from an approved role template and information supplied by HR. It should identify missing inputs, assemble the relevant tasks and draft requests for responsible teams. This is a design proposal, not a description of a confidential deployment.
The pipeline begins with ordinary checks: validate the request, confirm the requester’s permissions and select the approved template version. The model can interpret unstructured notes or explain a missing requirement. It should not invent an employee’s role, approve its own access request or decide that a mandatory security step is inconvenient.
Separate proposals from execution
I would keep draft creation separate from execution. The harness presents the proposed checklist with evidence, changes and unresolved questions. Approved actions then pass through a service that rechecks authorisation and parameters. For access provisioning, the identity system and designated approver remain the authority.
Tools should reflect that separation. “Read approved role template” and “prepare access request” are easier to reason about than a general administrator shell. OWASP’s excessive-agency guidance identifies overly broad functionality, permissions and autonomy as important sources of risk. OWASP — Excessive Agency Applying the boundary outside the prompt makes it harder for an unexpected model response to become an unauthorised action.
Plan for untrusted input and interrupted work
External text also needs a clear status. An attachment or retrieved page is evidence to interpret, not an instruction source allowed to rewrite the workflow. Prompt injection requires layered defences; instructions telling the model to ignore attacks are not a complete control. OWASP — LLM Prompt Injection Prevention
Operational reliability adds another layer. A timeout must not create the same task twice. An interrupted run needs enough durable state to resume sensibly. I would use stable operation identifiers, verify external outcomes and keep a recoverable record of completed steps. Persistence frameworks support checkpoints, but the application still needs to design its side effects and permissions. LangGraph — Persistence
The acceptance test follows the work: correct checklist, valid sources, missing information flagged, no unauthorised account changes, and no duplicated requests after retry. Completion is the verified state of the process, not an agent saying “done.”
Concrete use cases turn agentic architecture from a diagram into decisions a client can inspect. We can expand the action boundary later if evidence shows the system and the operating team are ready. That creates a useful path from a modest first capability to a more capable service, with a clear basis for every increase in autonomy.
Model Harness Engineering turns use cases like this into explicit tools, controls, evaluations and recovery paths. fdo.codes
