Building agents
Build and operate governed agents
An agent that cannot be proven before it ships is a liability. Agent Studio is where an organizational agent is designed, tested against the runtime's own authorization, published as a version you can diff and roll back, and then operated - all on the same models the runtime enforces, never a copy of them.
From a description to a published agent
Four stages, each producing something a reviewer can check rather than take on trust.
1 · Define
Give the agent a business and technical owner, a risk level, a sensitivity ceiling, and explicit limits on the tools, actions and task types it may use. An AI assist can draft these fields from a short description - it saves nothing until a person reviews and confirms.
2 · Grant
Explicit resource and operation grants, tools, workflows, scheduled runs and human approvals. Start from governed templates and business roles rather than an empty page.
3 · Prove
A Test Lab evaluates scenarios with the runtime's own authorization primitive rather than re-implementing it, so what passes in testing is what the runtime will do. A deterministic risk assessment sits beside it - a bounded helper, never a model's judgement, and it blocks nothing by itself.
4 · Publish
Publish a version with a field-level diff that shows where permissions widened, and roll a definition change back. Credentials are never held in a snapshot, and live resource grants are not reverted by a rollback.
Operating a published agent
What an operator sees once an agent is live, including the parts that are not flattering. Every number below is the product's behaviour today, not a target.
- Each run is recorded with its trigger, status, reason code, the exact agent version it ran under, step and tool-call counts and who started it. A run is bound to the version it started under, so a later edit never rewrites history. Four statuses are kept: completed, stopped, awaiting approval, error.
- A failed run is recorded with its reason and stays available as evidence, and one agent's failure does not stop the others. There is no automatic retry of a failed run and no alert — a scheduled agent is simply considered again at its next due time, and a failure waits to be noticed. Email is sent for a new approval request, not for a failure.
- A significant action - a data write, a high-impact or high-sensitivity step, an external call - pauses for a human decision, bound to an exact action plan. Separation of duties is the default, and any check that fails keeps it: a setting can allow a requester to approve their own request, and a compliance profile overrides that setting and requires a second person regardless. Read-only, low-impact work runs within policy without an approval.
- An approval request is valid for 60 minutes; once approved, execution has its own 30-minute window. Both are fixed in the product rather than configurable. An expired request is refused rather than quietly executed, and it leaves the approver's actionable list.
- The run history shows the newest runs — a bounded list rather than a searchable archive, with no filters today. What is kept is governance metadata: the decision and the evidence, never the agent's payload, prompt or secrets.
Running an agent from another system
An authorized integration client can start a run over HTTP, poll it and cancel it. Authentication is the gateway's own client credentials with an explicit agents:invoke permission, and the same client controls apply — an IP allow-list, an activity window and a daily cap. A short run returns its result; a longer one returns an invocation id to poll.
This starts runs. It is not a lifecycle SDK: creating, editing and publishing an agent definition happen in Agent Studio, and there is no public API for them. A poll reports a run as running with the time it started, and never guesses a final state it cannot observe.
A governed runtime, not an open framework
Vayon AI provides a governed runtime for enterprise agents and workflows, with explicit resource and operation grants, tools, scheduled runs, human approvals and auditable runs. Agents act within policy, and anything that mutates stops for a one-time human approval - not an open framework that runs arbitrary code.
Frequently asked questions
Does Agent Studio have its own permission system?
No, and that is the point. Agent Studio uses the same authoritative agent, workflow, resource and permission models as the runtime. There is no parallel permission system to drift out of step with what actually gets enforced.
Can an agent give itself more access?
No. Policy evaluation intersects the actor's authority, the agent's own grants, its workload identity and organizational policy - an agent can never widen its own authority. Before an approved action runs, the action-plan fingerprint, the agent's version, its lifecycle and the approval's validity are re-checked; if the agent or its plan changed, the approval no longer applies.
Is this a framework for running arbitrary code?
No. It is a governed runtime for enterprise agents and workflows, with explicit resource and operation grants, tools, scheduled runs, human approvals and auditable runs. Agents act within policy, and anything that mutates stops for a one-time human approval.