AI agents

Give the AI a job. Not a blank cheque.

An agent here is not a chat box with opinions. It is a job you configure: a set of tools it may use, an autonomy level that decides whether it suggests, asks or acts, and four ceilings it cannot argue its way past.

Six reasoning steps. Six thousand tokens. Forty-five seconds. Three write actions. Hit any of them and the run stops and hands back to a person rather than inventing an ending — and every step it took is still there to read.

Start free Book a demo

No credit card. Free plan, 2 seats, 50 AI credits a month.

Run — AR Collector · autonomy: approve

Read the overdue invoice

A granted tool, scoped to this workspace

Step 1

Read the contact and the thread

Real records, not a summary it was handed

Step 2

Draft the chase email

A draft tool. It cannot send from this one

Step 3

Queued for approval

Full payload attached. Approving is what sends it

Waiting

20
tools an agent can be given — 11 that read or draft, 9 that write
3
autonomy modes, set per agent before it runs
6
reasoning steps by default, hard-capped at 12
45s
wall clock, after which the run stops and escalates
3
write actions per run, counted across the whole run

Give it context. Define its authority. Start it. Read what it did.

Four decisions, and only the first three are configuration. The fourth is the part that decides whether an agent is something you can defend to a finance director in six weeks’ time.

Give it contextPoint it at the records it should work from — invoices, deals, tickets, stock, bank lines, your knowledge base. It reads them live and scoped to your workspace. When there is nothing there, it is told so rather than left to guess.
Define its authorityPick its tools from a catalog of twenty, and pick one of three autonomy modes. Those two choices are the whole of what it may do. A tool you did not grant is refused even if the model asks for it by name.
Start the run — a person starts itAgents run on demand. Oneop does not fire them on a schedule or from a record event today, so an agent does nothing between the times you use it. If you want something that starts by itself, that is the automation engine.
Read what it didEvery step keeps its reasoning, the tool it chose, the parameters it proposed and what actually came back. Plus how it ended, how long it took and what it cost. Including the runs that failed.

Context
The records it may read, live and scoped to your workspace
Authority
Its tools, and whether it suggests, asks, or acts
A run
Started by a person, bounded by four published ceilings
Evidence
Every step, every tool, every parameter — and how it ended

What an agent may do, and what decides it

Authority here is two separate questions that the industry usually blurs into one. Which tools does it hold, and at what autonomy does it hold them. Neither answer is the model’s to give.

Twenty tools, and the line down the middle of them

The catalog is fixed and an agent is granted a subset. The separation that matters is not between modules, it is between reading, working something out, drafting, and changing a record — because three of those four cannot alter your business at all, whatever the agent concludes.

The four classes of tool an Oneop agent can be granted, what each class can do, and what it cannot
Class	Tools	What it can do	What it cannot
Read	Contacts and deals · invoices · knowledge base · stock · bank lines	Look at records in your workspace, scoped to it.	Change anything at all.
Analyse	Bank matching · web enrichment · GL coding	Work something out and report it.	Apply it. Every one of these is analysis-only in the catalog itself.
Draft	Email draft · quote draft · article draft · purchase-order draft	Compose something for a person to look at.	Send, publish or issue it. The catalog entries read “no send” and “no publish”.
Write	Send email · update a contact · close a ticket · create, assign, complete or comment on a task	Change a record — but only through the one governed dispatch function.	Act above the autonomy you set, or more than three times in a run.
Money and stock	Post a bill · issue a purchase order · send a payment reminder · place a credit hold	Nothing, until somebody deliberately switches this class on.	Run at all while it is off — in any autonomy mode, and even after a person approves it.

Eleven of the twenty read or draft. Nine can write, and every one of those nine goes through the same governed dispatch — there is no second path to a record.

Three modes, chosen before it runs

Autonomy is stored on the agent, not passed in when you start it, so it is a property of the job rather than of whoever pressed the button. Changing it is a deliberate edit to the agent.

Suggest

It works the problem and tells you what it would do.

Nothing is written. The proposed action and its parameters are still recorded in the run trace, so “what did it want to do” has an answer, but no record in your workspace changes and no email leaves. This is where most agents should start and where several of the supplied templates start.

Approve

It works the problem and queues the action for a person.

The proposal becomes a durable row with its full payload attached, and it expires after forty-eight hours if nobody touches it. Approving is what executes it — the agent does not act first and ask afterwards. This is the mode most finance and outbound work belongs in.

Autonomous

It acts inside its tool set, without waiting.

The action dispatches immediately, but only through the same governed function the other two modes use, only using tools you granted, and only up to three times in a run. Money and stock stay locked off regardless. Autonomous means unattended by an approver — it does not mean unbounded, and it does not mean unattended by you, because the agent still only runs when a run is started.

Four ceilings, and a fifth that catches it going in circles

These are published rather than described because they are the numbers you would otherwise have to take on trust. They bound every run, they are counted across the whole run rather than per branch, and the step ceiling has a hard cap above it that configuration cannot raise.

What happens at a ceiling matters as much as the ceiling. The run does not fail silently and it does not push on to produce something. It ends as escalated, keeps the full trace, and stores which ceiling it hit — so a person resumes from a known position instead of starting again from a guess.

How Oneop constrains AI everywhere

6reasoning steps by default — hard-capped at 12 however it is configured
6,000tokens per run
45swall clock
3write actions, counted across the whole run
2identical observations in a row and the run ends as no-progress

What no agent may do, in any mode

No Oneop agent can post to your ledger, issue a purchase order, place a credit hold or send a payment reminder unless that entire class of action has been switched on separately — regardless of its autonomy mode, and regardless of whether a person approved it.

It ships off. While it is off, an agent that tries one is acknowledged and nothing happens — the boring outcome rather than an error it could route around. The block sits below the approval step, not beside it, so approving a queued money action while the switch is off still does nothing.

Switched on, those actions create or update draft records through the same service functions your own staff use, so double-entry and stock invariants apply to an agent exactly as to a person. Posting a bill to the ledger remains a separate, deliberate human approval, and no setting removes that step.

Connected with Oneop

It acts on the same records your people do

An agent is not looking at a copy of your business through an API. Its read tools query the same invoices, deals, tickets, stock levels and bank lines your staff have open, in the same workspace, and its write tools change those same rows through the same service functions — which is why the accounting and stock rules that protect your books from a mistyped human entry protect them from a model too. This is also what makes the tool catalog meaningful rather than decorative: giving an agent invoice reads and no invoice writes is a real boundary because there is only one set of invoices. There is no connector to configure between an agent and the rest of Oneop, because there is nothing in between them.

You are hereAI agentsAI acts on the same records people do, under limits that are published rather than described.

The other 6 modules sit on the same record, and reach AI agents the same way:

Beyond the four

Eight agents ready to configure

A collections chaser, a bill capturer, a lead qualifier, a quote drafter, a ticket triager, a knowledge-base author, a reorder planner and a bank-reconciliation matcher. Each arrives with a tool set and a default autonomy already chosen — the collections agent asks permission, the article author only suggests.

Run it as a simulation first

A simulated run walks the whole approval lifecycle and produces a full trace, calls no model, writes no credit-usage row, and is badged Simulated in the interface. It stores no confidence score at all rather than inventing one, so a demo can never be mistaken for a real result.

Prompt injection is blocked unconditionally

Instructions hidden inside a record an agent reads — a ticket body, a note, an enriched web page — are checked on every reasoning step and refused. It is not a setting, and there is nothing to switch on, because a control you can forget to enable is not a control.

A run that stops says why it stopped

Nine distinct exit reasons are stored, not one failure state: goal reached, out of steps, out of tokens, out of time, no progress, blocked by a guardrail, tool error, escalated to a human, or out of credits. A billing stop and a provider outage are deliberately different answers.

It stops repeating itself

Two identical observations in a row end the run as no-progress. An agent that has started going in circles burns your credits and your patience at the same rate, and the loop that catches it is cheaper than the one that does not.

One workspace, enforced below the agent

Every tool call carries the run tenant, and a build-breaking test fails the whole product if any agent-surface model call omits it. The isolation is not a rule the agent is asked to follow; it is a parameter it cannot construct a call without.

Agents do not connect to your tools. They read what the tools filled in.

There is no agent connector to configure and no per-agent credentials to store, because an agent never talks to an outside system. It reads Oneop’s own tables. What the integrations below do is put rows in those tables — deals synced from HubSpot, orders from WooCommerce, payments through Stripe, leads captured on WordPress, messages from a mailbox. A row that arrived that way is indistinguishable to an agent from one somebody typed. The single route outward is an agent’s email tool, which sends through whichever provider your workspace already uses.

See all integrations

HubSpot
WooCommerce
Stripe
WordPress
Gmail
Microsoft 365
SendGrid
Webhooks

For the technical evaluator

The run is written down before the first billed step.

Not after it succeeds. Which means a run that dies halfway is visible rather than absent — and there are two things that does not make true, named below rather than left for you to find in an audit.

What the claim covers, and the limits it does not

Why the ordering is the whole argument. The natural way to record an agent run is to run it and then write down what happened. That works until the process ends mid-run, which it does on every deploy and every crash — and when it does, the run vanishes while the credits it consumed do not, because those were charged call by call as it went. The tenant is billed for work that left no trace. It is a particularly bad failure because it is invisible from both directions: the run history looks clean, and the usage line looks like a mistake.

What we do instead. The run row is inserted before the loop starts, carrying the agent, the workspace and the task, at status running. It is then updated in place — on the way out through success, and on the way out through failure, which is the same code path either way rather than a happy path with a catch bolted beside it. A row still sitting at running is therefore not a mystery: it is the visible signature of a run that was interrupted, and it is supposed to be there.

What the row carries. Every step keeps four things — what the agent was reasoning, which tool it chose, the parameters it proposed, and what actually came back from that tool. Then the run keeps how it ended, out of nine distinct exit reasons, along with duration, tokens and cost. That means a suggestion-only run is still fully accountable: the action it wanted to take is recorded with its payload even though nothing was written, so “what would it have done” is answerable after the fact rather than being a question you have to re-run to answer.

Confidence is derived or it is nothing. The score attached to a run comes from a real scoring pass, and when that pass cannot produce one the field is null and the interface shows a dash. It is never defaulted, never inferred from the agent’s settings, and never invented — a simulated run in particular stores no confidence at all rather than a plausible-looking number. It is also worth being clear about what the score is: a model’s own assessment of its answer, which is useful for sorting a review queue and is not a calibrated probability.

The first limit: an interrupted run can over-count credits, never under-count. Credits are reserved before a call and released if the provider produced nothing, so a failed call is refunded and a response that comes back unusable is refunded too — which is also why the retry inside the loop cannot bill you twice for the same step. The window that remains is the other direction: if the process dies between a provider returning successfully and the ledger being reconciled, the reservation stands. You may be charged for a step whose result you never received. We would rather that error ran that way round, and we would rather say which way round it runs.

The second limit: the model recorded is the one configured. If the router falls back through its chain of Gemini models, the run still reports the model the agent was set to use. Nothing about the run is wrong except that field, but it is a field an evaluator would reasonably read as observed rather than declared, so it is named here.

Why this is the guarantee we surface. Because the interesting question about an AI agent is not what it does when it works. Every product in this category can show you that. It is what is left behind when it does not — and whether the answer to “what did it do in March” is a record or a reconstruction.

What it costs

There is no AI tier. Configuring agents, all three autonomy modes, the approvals queue and the full reasoning trace are on every plan including the free one — the entitlement is enabled everywhere, so there is nothing there to unlock. What moves is the last line, and it is a number rather than a tick.

Credits are charged per model call at a weight of five, so a run that thinks for its full six steps and then scores itself is around thirty-five. Read the free plan’s fifty as one full run and a short one — enough to judge whether you trust it, not enough to operate on. That pool is shared with every other AI feature in Oneop rather than reserved for agents.

See full pricing

Which AI agent capabilities are included on each Oneop plan
Plan	Configure agents, tool sets and autonomy	All three autonomy modes, including approvals	Full reasoning trace on every run	Simulated runs, which cost nothing	AI credits a month, shared with the rest of Oneop
Free $0	Included	Included	Included	Included	50
Starter $19	Included	Included	Included	Included	1,000
Pro $59	Included	Included	Included	Included	5,000
Business $129	Included	Included	Included	Included	15,000

Frequently asked

Can an agent run on its own, on a schedule or when a record changes?

No, and this is the thing we would least like you to discover after buying. An agent in Oneop runs when a person starts a run. There is no scheduler behind it and no event that fires it: the product will let you define trigger rules against events, but nothing in Oneop currently evaluates them, so a rule you write there will not fire. We would rather tell you that than let you build a process on top of it. What "autonomous" means here is precise and narrower than the word usually implies — it describes whether the agent needs an approver before it acts, not whether it starts by itself. If you want something that genuinely starts on its own when a deal closes or a ticket goes quiet, that is the automation engine, which does have real event triggers and a real scheduler, and it is a separate part of the product.

What actually stops it doing something stupid?

Six things, and all six are code rather than policy, which is the distinction that matters when you are deciding whether to trust it. The tool set is a fixed catalog and an agent is given a subset of it; a tool the model names that is not in that subset is refused rather than improvised. Four ceilings bound every run — six reasoning steps by default with a hard cap of twelve however it is configured, six thousand tokens, forty-five seconds and three write actions counted across the whole run. Repeating itself ends the run. Every write goes through one dispatch function that applies your autonomy mode, so there is a single place where an action becomes real. Money and stock actions are fail-closed behind a separate switch regardless of that mode. And prompt-injection checks run on every step and cannot be turned off. Hitting any ceiling ends the run as escalated with the trace kept, so a person picks up where it stopped rather than the agent inventing an ending to finish.

Can an agent post to my ledger or move stock?

Not unless somebody has deliberately switched that class of action on, and it is off until they do. While it is off, an agent that decides to post a bill or issue a purchase order gets an acknowledgement and nothing happens — in autonomous mode, and even after a human has approved it, because the block sits below the approval rather than beside it. Switched on, those actions create or update draft records through the same service functions your own staff use, so they inherit the same double-entry and stock invariants. Posting a bill to the general ledger still requires a separate, deliberate approval by a person afterwards. There is no configuration in which a model writes to your accounts unsupervised.

What does a run cost, and what do I get on the free plan?

Credits are charged per model call, not per run, and an agent call is weighted at five. A run that thinks for the full six steps also makes a closing pass to score its own confidence, so it is seven calls and about thirty-five credits. A run that reaches its goal in two steps is nearer fifteen. The free plan includes fifty credits a month, which is honestly about one full run plus a short one — enough to configure an agent, watch a real trace end to end and decide whether you believe it, and not enough to operate anything. Simulated runs make no model call at all and cost nothing, so you can exercise the approval flow as many times as you like. Two things are worth knowing about how the meter behaves: guardrails run before credits are reserved, so a blocked prompt is never charged, and a call whose response comes back unusable is refunded rather than billed.

How is an agent different from the chatbot, or from an AI step in an automation?

The chatbot follows a flow you drew. The same input walks the same path every time, which is exactly what you want facing the public. An AI step inside an automation is a single model call whose output becomes a variable your rules then branch on — the model informs a decision, your flow makes it. An agent is the only one of the three that chooses its own path: it is given a goal and a tool set, and it decides which tool to reach for next, one step at a time, until it finishes or hits a ceiling. That freedom is why it earns ceilings and an authority model that the other two do not need, and it is why we do not call an automation AI step an agent anywhere on this site. Most teams end up running all three.

Which model does it use, and can I choose?

Google Gemini, exclusively, with a reasoning model for the loop itself and a faster one for cheap paths like the confidence pass. There is no model picker, no multi-provider routing, and no OpenAI or Anthropic support anywhere in the product. If a call fails, the router falls back through a chain of Gemini models rather than to another vendor. One honest detail: the model recorded against a run is the one it was configured to use, so if a fallback served the call, the run record does not currently reflect that. It is a reporting gap rather than a routing one, and we would rather name it here than have you find it in an audit.

Can an agent see another workspace’s data?

No. Every read an agent performs is scoped to the workspace the run belongs to, and that scoping happens in the data layer rather than in the prompt — the agent is not asked to respect a boundary, it is handed a query it cannot widen. A test in the build fails the entire product if any model call on the agent surface is made without a workspace attached, which also means AI usage can always be attributed to somebody. When a read finds nothing, the agent is told there is nothing on file rather than being left to fill the gap, which is the difference between an agent that reports an empty pipeline and one that describes an imaginary deal.

Decide for yourself, on your own records.

Configure one agent with read-only tools — it cannot change anything, and you will see exactly how it thinks. Or book a walkthrough and we will show you a run stopped at an approval, a run stopped at a ceiling, and a money action refused with the switch off.