How Actus Agent Works: Planner, Executor, Verifier, and Real Tool Use

How Actus Agent Works: Planner, Executor, Verifier, and Real Tool Use

An AI agent is only as useful as the system around its model. A language model can interpret a request and propose a plan, but completing real work requires far more: tools, execution state, permissions, retries, cost controls, memory, evidence, and a reliable way to decide whether the job is actually finished.

Actus Agent is designed around that full operating loop. Its core pattern is planner → executor → verifier. A task may begin in chat, on a schedule, through a webhook, or from a connected messaging channel. The same orchestrator then converts the goal into actions, calls real tools, inspects results, and returns a finished artifact or an honest explanation of what blocked completion.

This guide explains each layer and why the architecture matters for businesses evaluating autonomous AI.

Why a model alone is not an agent

A language model produces predictions. It can write a plausible sequence of actions, but it does not automatically possess access to browsers, files, business systems, code environments, or communication channels.

OpenAI’s practical guide to building agents describes three foundational components: a model, tools, and instructions. Anthropic’s Building Effective Agents similarly distinguishes flexible agents from predefined workflows.

The model is the reasoning engine. The surrounding platform turns reasoning into controlled action.

The planner: converting intent into executable work

Users rarely express a complete technical specification. They say, “Build a competitor report,” “Find qualified businesses,” or “Create and deploy a landing page.”

The planner translates that objective into a sequence with concrete completion criteria. For a competitor report, it might identify the target companies, select authoritative sources, collect current data, compare findings, create a document, validate it, and deliver it.

A strong plan should answer:

• What is the desired final state?
• Which information is required?
• Which tools are permitted?
• Which actions can run in parallel?
• Which actions depend on earlier results?
• What evidence proves completion?
• Which decisions require approval?
• When should the run stop?

Actus supports plans spanning multiple tool calls while applying iteration limits so an unclear objective cannot create an infinite loop.

The executor: using real tools

The executor performs the planned steps. Depending on the task, it may search the web, navigate a browser, extract structured data, run code, create a spreadsheet, produce a PDF, build a Next.js site, generate brand imagery, or interact with connected services.

The difference between simulated and real execution is measurable. If an agent says it created a file, there should be a downloadable file. If it says a website was deployed, there should be a live deployment result. If it says data was collected, the structured rows and sources should exist.

Actus exposes more than 50 live tools and gives each run a sandboxed execution environment. This allows the agent to work with Node, Python, common command-line utilities, and generated files without treating code as decorative text.

Parallel tool calls

Not every step must wait for the previous one. Researching independent competitors, checking several sources, or validating multiple files can happen concurrently.

Actus runs independent tool calls in parallel when the plan allows it. This matters because sequential dispatch adds every individual delay together. Parallelism reduces end-to-end time while preserving dependency order for steps that truly rely on one another.

Parallelism also needs limits. Too many simultaneous browser sessions or model calls can exhaust rate limits, increase cost, or create conflicting writes. The orchestrator must understand both logical independence and operational capacity.

The verifier: proving the result

Many agent failures are not failures to act; they are failures to verify. A system clicks “Submit” and assumes the form was accepted. It writes code and assumes the build passed. It prepares an email and claims the message was sent.

Actus performs a claim-verification pass before delivering the final response. Statements about completed actions are compared with the tools that would have needed to succeed. If the evidence is missing, the system gets one opportunity to perform the action or rewrite the response honestly.

Verification should be task-specific:

• A generated document must exist and open.
• A spreadsheet should contain required columns and valid rows.
• A website should build successfully and return a reachable URL.
• A sent email needs a successful sending result.
• A saved record should be fetched again and compared.
• A research claim should link to the source that supports it.

The NIST AI Risk Management Framework encourages measurement and governance throughout the AI lifecycle. In agent operations, evidence-based completion is one of the most practical applications of that principle.

Context management

Long agent runs accumulate instructions, observations, files, errors, and tool outputs. Eventually, the context becomes too large or too noisy for effective reasoning.

Actus monitors context use. When a run approaches roughly 80 percent of its available window, older messages are compressed into a working summary while explicitly pinned information survives. The goal is not simply to retain everything; it is to preserve the facts and constraints that still matter.

Good context management prevents an agent from forgetting the objective, repeating completed steps, or losing a critical prohibition late in the run.

Memory and reflection

Context serves the current run. Memory helps future runs.

Before a task starts, Actus can retrieve relevant saved facts and reflections from similar work. After completion, a separate assessment records what worked, assigns a candid score, and captures concrete lessons.

This creates an improvement loop. A recurring report should not rediscover the same source problem every week. A website-building agent should remember which deployment failure occurred and how it was resolved.

Memory must remain selective. Irrelevant history consumes context and can distort decisions. Retrieval should be based on relevance to the current objective.

Model fallback

Production systems cannot assume that one model endpoint will always respond. Providers experience outages, rate limits, regional disruptions, and transient errors.

Actus uses a fallback chain. A BYOK user’s own key is attempted first. If that path fails, the run can move through platform models and additional backup routes. A model outage therefore does not automatically destroy the entire workflow.

Fallback requires compatibility. Tools, structured outputs, context limits, and behavior differ across models. The orchestrator must preserve task state while adapting the request.

Budgets and iteration limits

An autonomous loop needs real boundaries. Actus checks the run budget and account-wide cap during execution, not merely after generating an invoice. It also caps iterations, with a default run budget and a hard upper ceiling.

These limits protect both cost and behavior. A stuck browser loop should stop. Two concurrent runs should not independently spend against the same remaining balance. An agent should know when additional effort is unlikely to justify its cost.

The Actus pricing page explains current credits, plans, top-ups, and BYOK availability.

Approval gates

Not every successful plan should execute automatically. Sensitive actions should pause for a person.

Researching public information is usually low risk. Sending external messages, spending money, changing access, publishing content, or deleting records carries greater consequences.

Actus provides an approval queue so the agent can prepare the work, preserve its state, and wait. This is graduated autonomy: automate what is safe, review what is consequential.

The OWASP Top 10 for LLM Applications identifies excessive agency and prompt injection as key risks. Tool allowlists and approval gates reduce the damage an untrusted instruction can cause.

Retry behavior and idempotency

Transient failures should not permanently fail a scheduled process. Actus scheduled runs can retry with exponential backoff. But retrying a write without checking state can create duplicates.

Reliable tools should use idempotency keys or fresh collision checks. If a post may already have been created, fetch it before retrying. If an email send produced an ambiguous response, check the provider state rather than sending again.

The AWS Builders’ Library provides useful engineering guidance on timeouts, retries, backoff, and idempotent operations.

How a complete Actus run flows

A typical run follows this pattern:

1. A chat, schedule, webhook, or connected channel triggers the task.
2. Relevant instructions, memory, and account controls are loaded.
3. The planner decomposes the objective.
4. The executor calls approved tools, concurrently where safe.
5. Observations update the plan.
6. Approval gates pause consequential steps.
7. Retries address transient failures.
8. The verifier compares completion claims with tool evidence.
9. Artifacts and a final result are delivered.
10. Reflection captures lessons for similar work.

This is what turns a conversational request into an operating process.

What businesses should evaluate

When comparing agent platforms, ask more than which model is used.

• Can it call the tools required for your workflow?
• Does it return real files and external results?
• Are budgets enforced during the run?
• Can actions require approval?
• How are retries and duplicates handled?
• Can the run survive a model outage?
• Is there a trace of what happened?
• Does it verify claims before reporting success?
• Can agents run on schedules and event triggers?
• Can teams separate roles and permissions?

A model may change next month. Architecture determines whether the work remains trustworthy.

Final perspective

The planner, executor, and verifier are not marketing labels. They represent three different responsibilities: deciding what to do, doing it through real tools, and proving that the result exists.

Explore Actus Agent with a task that has a clear artifact and definition of done. Inspect the execution trace, not just the final paragraph.