Skip to content
VEYQON
Platform · Core/AGT

An agent is a job description, not a chat box.

Each agent holds a role, a set of tools it may use, and a limit it cannot cross. You read exactly what it did and why, on the record it did it to — and you can take the job off it mid-flight and finish it yourself.

Role library·Explicit tool permissions·Human gates

What it does · 24 capabilities/01

What defines an agent here.

Six things, all of them written down before the agent runs. An agent that cannot be described this way is a prompt with a schedule attached.

01

The role

What it is responsible for, and what it may see.

  • A named post

    Accounts payable, buyer, dispatcher, close preparer. Named the way you would name the job if a person held it.

  • Data scope

    Companies, cost centres, warehouses, and document types it may read, enforced by the same row-level rules as a person.

  • A human owner

    One named person accountable for what this agent does, which is what makes the quarterly review a real review.

  • A written responsibility

    One paragraph saying what this agent is for. If it cannot be written, the agent should not exist yet.

02

The trigger

What starts it, so nothing waits on somebody remembering.

  • An arriving document

    An invoice in the mailbox, a supplier delivery note, a statement import — the event, not a poll.

  • A threshold breach

    Projected quantity through a reorder level, a margin below a floor, an SLA clock approaching its target.

  • A date

    Period end, a payment run, a maintenance schedule, a contract renewal window.

  • A state change

    A document moving between workflow states, which is how one agent's output becomes another's input.

03

The toolset

The specific actions it may take, and nothing adjacent.

  • An explicit list

    Not a category. 'Match a purchase invoice' is a tool; 'work with invoices' is not, and would not be accepted.

  • Read and write separated

    Reading a payment and creating one are different permissions, granted separately.

  • Draft versus submit

    Most agents hold draft rights and not submit rights. That single distinction covers a great deal of the risk.

  • Outbound gated

    Contacting a supplier or a customer on your behalf is its own permission, off by default.

04

The limit

The ceiling, and what it may never do alone.

  • Value ceiling

    Per document, per period, and in aggregate. Three separate numbers, because they fail differently.

  • Variance tolerance

    How far a match may be out before it stops being a match and becomes a person's decision.

  • Volume cap

    How many documents it may touch in a period, so a bad rule is caught at fifty rather than at five thousand.

  • Never-alone list

    Named actions that always require a second party, whether that party is a person or another agent.

05

The escalation

Who it hands to, and what they see when it arrives.

  • A named person

    Not a queue and not a distribution list. Escalation to a group is how items sit for a fortnight.

  • Context attached

    The source documents, the difference, and the reasoning — so approving takes seconds rather than an investigation.

  • A time limit

    How long it waits before escalating again, and to whom above them.

  • Handover mid-flight

    A person can take a job off an agent while it is working and finish it themselves, with the partial work intact.

06

The trail

Readable by anyone with access to the record, months later.

  • On the document

    The reasoning lives on the record it touched, not in a separate observability tool with a retention policy.

  • Inputs listed

    Which records it read, so a wrong conclusion can be traced to the document that caused it.

  • Limit shown

    Which ceiling permitted the action, so an auditor can see the authority as well as the act.

  • Replay

    Re-run against the same records to see exactly what happened, without guessing from a log line.

In production/02

Four agents doing real work.

Named as they appear in the queue. Note what each one stops short of — that is not a limitation of the model, it is the configuration.

  1. 01

    ap-clerk

    Three-way matches invoices against the PO and goods receipt, and posts when variance is nil.

  2. 02

    buyer-agent

    Issues RFQs, normalises quotes, and drafts a purchase order. Never sends it.

  3. 03

    dispatch-agent

    Checks the SLA clock, matches skills to engineers in range, and prices the callout.

  4. 04

    close-agent

    Posts recurring accruals, flags unreconciled bank lines, and drafts variance commentary.

The spec/03

The specification.

What governance will ask for when the agents come up in a board paper.

Definition
Role, trigger, toolset, limit, escalation, owner — all required
Permissions
Row-level, identical to a person's, applied before inference
Ceilings
Per document, per period, aggregate, and volume
Segregation
Enforced across a chain, not only per agent
Default posture
Proposal mode; autonomy granted per action
Audit
Reasoning, inputs, and governing limit on the document
Interruption
Human handover mid-flight, partial work preserved
Rollback
Any agent returns to proposal mode immediately
Where it stops/04

What an agent is not allowed to be.

These are constraints of the design rather than of the current version, so they will not be lifted in a later release.

Not unbounded
There is no 'full autonomy' setting. Every action an agent can take is one somebody explicitly granted, under a ceiling somebody set.
Not a second permission model
Agents do not get a parallel, more convenient set of rules. They sit inside the one your people are in.
Not self-approving
It cannot approve what it raised, and a chain of three agents cannot launder an approval between them.
Not silent
There is no mode in which an agent acts without writing to the audit trail. Turning that off is not a feature we will build.

Next step

Bring one process. We will run it live.