Intelligence that reads your own ledger.
A model that can summarise a document is not much use to an operations team. VEYQON AI is grounded in your live records, holds a role, and works inside limits you set — so it can check a credit limit, split a batch, and post a journal.
Grounded in live records·Role-scoped·Every step logged
Not a chat window bolted onto an ERP.
Five areas. The first is what makes an answer trustworthy; the rest are what make an action safe. Most products in this category have the first and not the rest.
Grounding
Where an answer comes from, and how you check it.
Live records, not a snapshot
Retrieval runs against the current documents, so an answer about stock is the stock position now rather than at last night's export.
Permissions applied at retrieval
An agent cannot surface what its role could not open. The permission check happens before the model sees anything, not after.
Cited answers
Every reply names the documents behind it and links to them, so the answer is checkable in one click rather than trusted.
Structured and unstructured together
Ledger rows, document fields, and attached files are all retrievable, so a question about an invoice can read the PDF and the posting.
Says when it does not know
Where the records do not contain the answer, that is the answer. It does not fill the gap from general knowledge.
Roles
An agent is defined the way a job is defined.
Scoped like a post
Accounts payable, procurement, dispatch, period close — each with a written responsibility rather than a prompt.
Explicit tool permissions
A named list of the actions it may take. Matching an invoice does not imply paying one, and the system enforces the distinction.
Data scope per role
Which companies, cost centres, warehouses, and document types it may read, using the same row-level rules as a person.
Named human owner
Every agent has a person accountable for it, which is what makes a review meaningful.
Limits
The part that decides whether any of it can go live.
Value ceilings
Per agent, per period, and per document type. A ceiling cannot be crossed however the agent is asked to cross it.
Segregation of duties
An agent cannot approve what it raised. The rule that applies to your people applies to your agents, and it is tested across a chain, not per step.
Human approval gates
Anything over a limit routes to a named person with the reasoning and the source documents attached.
Proposal mode
Any agent can run proposing rather than acting, indefinitely, and be returned to it instantly without stopping anything else.
Blast radius
A cap on how many documents one agent may touch in a period, so a bad rule is a contained incident rather than a weekend.
The trail
What you can read back, months later, without a specialist.
Reasoning on the document
The steps an agent took are written to the audit trail of the record it touched, not to a separate log that ages out.
Inputs recorded
Which documents it read to reach a conclusion, so a wrong answer can be traced to the record that misled it.
Replayable
A run can be replayed against the same records to see exactly what happened, which is what an auditor asks for.
Attributable
Every posting shows whether a person or a named agent made it, and under which limit.
Where the model runs
The question every security review opens with now.
Your choice of provider
A hosted frontier model, a model in your own cloud tenancy, or an open-weights model on your hardware.
No training on your data
Your records are not used to train a shared model. This is a contractual term, not a setting.
Region pinning
Inference can be pinned to a region, which is usually what a data-residency clause actually requires.
Degrades safely
If the model is unavailable, the ERP keeps working. Agents queue; nothing blocks on inference.
How a question becomes an action.
Four steps, in this order, every time. Step three is where most products in this category simply act, and step four is where most of them keep nothing.
- 01
Retrieve
The question resolves against live records with your permissions applied, not against a snapshot.
- 02
Reason
The agent plans the steps and checks each one against the limits on its role.
- 03
Act
Permitted actions run. Anything beyond the limit is proposed rather than done.
- 04
Record
The reasoning is written to the document, so the decision can be read back months later.
The specification.
What a security review and an architect will each want in writing.
- Model hosting
- Hosted, your cloud tenancy, or open weights on your hardware
- Training
- Your data is never used to train a shared model
- Retrieval
- Live records, row-level permissions applied before inference
- Citations
- Every answer names and links the documents behind it
- Limits
- Value, period, and document-type ceilings per agent
- Audit
- Reasoning written to the touched document, replayable
- Failure mode
- ERP continues; agent work queues rather than blocking
- Residency
- Inference pinnable to a region
What it will not do.
Stated here because the alternative is discovering it during a security review, which is a worse place to find out.
- It does not act without a limit
- There is no configuration in which an agent has unbounded authority. If you want that, this is the wrong product.
- It does not approve its own work
- Segregation of duties is not a toggle. A chain of agents cannot compose its way around it either.
- It does not answer from general knowledge
- If your records do not contain the answer, it says so. Pleasant-sounding invention is the failure mode this design exists to prevent.
- It does not make clinical or legal judgements
- In healthcare it prepares, checks, and prompts. It does not diagnose, prescribe, or alter a clinical record.
- It is not accurate by assertion
- You get an accuracy figure from a full period in proposal mode on your own records. We do not quote somebody else's benchmark.
Next step