Skip to main content

AI agent development

Give the agent a bounded task, not broad authority.

Werkon builds agentic workflows that can gather context, prepare a plan, and use narrowly defined tools under deterministic permission checks. High-impact actions wait for the right person, and every action path needs evidence, limits, logs, revocation, and recovery.

Agent contract

Bind intent, identity, tools, and approval into one action system.

An agent is more than a conversation. The delivery boundary includes every source it reads, every state it remembers, every tool it can call, the identity used downstream, and what happens before and after an action is accepted. Compare agent use cases by the action each system may take, and review why agents fail in production before granting tool access.

Inputs

Bounded task and outcome
The initiating user, goal, permitted sub-tasks, completion condition, non-goals, limits, affected people, stop conditions, and what useful coordination looks like.
Context and memory
Authoritative records, retrieved knowledge, conversation state, task state, provenance, sensitivity, tenant or user boundary, retention, expiry, correction, and deletion needs.
Tools and identity
Narrow functions, schemas, downstream systems, authenticated user context, service identities, scopes, credentials, rate limits, idempotency, reversibility, and tool owners.
Action and consequence
Read, draft, propose, execute, approve, reject, override, escalate, audit, revoke, and recover paths, including the consequence of ambiguous or manipulated behavior.

Outputs

Agent operating contract
A visible definition of intended task, identity, context, memory, tools, permissions, action classes, approval policy, limits, owners, and behavior outside intended use.
Permissioned tool layer
Specific validated functions with minimum downstream privileges, user or tenant scope, deterministic policy, short-lived credentials where appropriate, audit fields, and safe error handling.
Evaluated action loop
A working agent path tested for task quality, direct and indirect injection, tool misuse, permission bypass, memory poisoning, data leakage, loops, cost, interruption, and recovery.
Operating and handover pack
Source, configurations, evaluation assets, tool contracts, policy, logs, dashboards, incident steps, kill and revoke paths, provider dependencies, documentation, and ownership context.

Agent development path

Design the action boundary before connecting a live tool.

The first complete slice should use the smallest context and least powerful tools that can demonstrate the task. Authority grows only when evidence supports the next action class.

  1. 01

    Map task and action classes

    Define intent, inputs, completion, affected systems, read, draft, propose and execute actions, approvals, stop conditions, and the people accountable for each boundary.

  2. 02

    Design identity and policy

    Bind the initiating user, agent session, tenant, tool, downstream authorization, data scope, credential lifetime, rate limits, approval policy, and revocation path.

  3. 03

    Build a reversible loop

    Connect representative context to narrow validated tools, deterministic policy, preview, confirmation, idempotency, audit, timeout, cancellation, and safe fallback.

  4. 04

    Attack and evaluate the boundary

    Test direct and indirect injection, malicious content, ambiguous intent, tool errors, permission bypass, memory poisoning, data crossing, loops, exhaustion, partial failure, and unsafe trust.

  5. 05

    Release, monitor and revoke

    Stage access, watch task and security signals, review approvals and overrides, investigate incidents, rotate credentials, disable tools, stop sessions, recover state, and reassess changes.

Action authority

Separate what the agent can see, prepare, recommend, and do.

The same tool may support several action classes, but the permission and approval path should reflect the consequence of each operation rather than the confidence of a generated plan.

01Retrieve task-relevant context

Read

Allow access only to the records, fields, sources, users, tenants, and time window needed for the current task, with provenance and missing-data behavior visible.

Evidence: User authorization, downstream scope, field limits, tenant isolation, query validation, access log, sensitivity checks, and denial tests.

02Prepare without changing a system

Draft

Create a response, document, plan, update, or tool argument in a non-authoritative state that a person or deterministic component can inspect and revise.

Evidence: Source support, validation, untrusted-output handling, clear draft state, edit path, no live side effect, and disposal behavior.

03Show the exact action before approval

Propose

Present target, fields, consequence, source evidence, warnings, alternatives, and the current authorized approver before a high-impact or irreversible tool call is possible.

Evidence: Deterministic policy result, diff or preview, current data, approver identity, expiry, confirmation, rejected-action log, and replay protection.

04Perform only a pre-authorized action

Execute

Use a narrowly defined tool under current user or service authority, validate every argument, constrain side effects, record the result, and preserve cancellation, recovery, and escalation.

Evidence: Per-action authorization, least privilege, schema validation, idempotency, rate limit, audit, result verification, rollback or compensation, and revocation.

Agent security boundaries

Treat model plans, retrieved content, memory, and tool output as untrusted.

Security does not come from asking the model to behave. Trusted application and downstream systems enforce identity, authorization, validation, isolation, approval, audit, and stop controls even when the agent is confused or manipulated. OWASP describes excessive agency in terms of unnecessary functionality, permissions, or autonomy; these boundaries need explicit controls.

Permissions live outside the model
Tool availability, user and tenant scope, fields, actions, limits, approvals, and downstream authorization are enforced by policy and system identities. Generated intent cannot expand them.
Credentials stay out of context
Secrets are never placed in prompts, browser-visible state, retrieved documents, memory, generated tool arguments, or logs. Trusted executors inject narrowly scoped credentials only when authorized.
Memory is isolated and governed
Task, session, user, and tenant state have explicit provenance, write rules, retention, expiry, correction, deletion, and cross-context isolation. Untrusted content cannot silently become durable policy.
Stop paths remain independent
Timeouts, call and cost caps, cancellation, tool disablement, credential revocation, session termination, rollback, incident response, and recovery do not depend on the agent choosing to cooperate.

Engagement fit

Use an agent when controlled coordination adds value beyond one model response.

Good reason to begin

  • A bounded task needs several context, reasoning, and tool steps whose sequence varies within a controlled operating workflow.
  • The organization can define user identity, downstream permissions, action classes, approvers, source authority, evaluation cases, and an accountable operating owner.
  • Drafting and proposing actions would reduce coordination burden even if execution remains human-approved.
  • The task can begin with narrow, reversible tools and expand only through evidence-backed permission decisions.

Resolve before beginning

  • The goal is broad autonomy, an undefined digital employee, or access to every system rather than one bounded task.
  • The agent would rely on shared high-privilege credentials, cross-tenant context, open-ended shell, database, browser, or network tools without enforceable scope.
  • No responsible owner can define approvals, respond to incidents, revoke access, review logs, or decide when the agent must stop.
  • The proposed action requires qualified or regulated authority that has not been secured outside the agent.

Source basis

Sources behind the control model.

  • 01

    OWASP GenAI Security Project

    LLM06:2025 Excessive Agency

    Current guidance to minimize tool functionality, permissions, and autonomy, execute in the user's authorization context, and require approval for high-impact actions.

  • 02

    NIST National Cybersecurity Center of Excellence

    Software and AI Agent Identity and Authorization

    A current concept-stage NIST project exploring agent identity, authentication, authorization, least privilege, delegated authority, audit, and prompt-injection controls.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore AI services

Compare agent development with automation, integration, custom AI, model, language, vision, deployment, and support responsibilities.

Open path02

Build a custom AI system

Use the broader system-development path when tool coordination is only one part of the required capability.

Open path03

Build an AI opportunity roadmap

Test whether agentic coordination is the right investment before granting tools or delivery scope.

Open path04

Review the proof standard

Define the evidence required for action quality, exceptions, ownership, and client-approved claims.

Open path