Autonomous Agents
An autonomous agent gets instructions, a set of tools, and a goal, then decides which tools to call and how to answer. There is no pipeline to draw; the model controls the flow. (For the opposite approach, where you wire each step yourself, see workflow agents.)
What makes them more than a prompt: several models collaborate inside one agent, the output is verified before it returns, the agent keeps memory and constraints across runs, and good runs become reusable skills. You set all of this up on the agent’s detail page.
Multiple models in one agent
An autonomous agent has one primary model that does the work and any number of verifier models that review it. Each can use a different provider, so one agent can span vendors — the Customer Support Orchestrator above runs GPT-4o as primary with a GPT-4o reviewer and a Gemini reviewer. The Models & Verification panel on the detail page shows the lineup.
Verification
Open the Models & Verification panel and click Configure to set up verification: add reviewer models (each with its own provider and focus instructions), choose how their verdicts combine, decide when they run, and set how many times the agent may revise.
Reviewers are refute-only — each tries to find a reason the answer is wrong. How their verdicts combine:
| Policy | The answer passes when |
|---|---|
| All pass | every reviewer approves |
| Majority | most reviewers approve |
| Any fail blocks (default) | a single failure blocks it |
When verification runs:
- On final output is a gate. The answer is reviewed before it returns. On a failure the agent gets the feedback and revises, up to the revise budget (default two), then completes. The run records the verdict, how many revisions it used, and whether it ran out of budget.
- Mid-run (every N steps, or after a tool result) is advisory: it injects a course-correction note without ending the run, so the agent can adjust before going further.
Workflow agents get the same capability as a verify node; the logic is shared between the two modes.
Collaboration
Verification puts several models inside one agent. Collaboration goes the other way: point an agent at several other agents and choose how they work together. Each member can be a different model, and the judge that settles the result can be a different model again.
| Mode | What it does |
|---|---|
| Sequential | Members run one after another, each fed the previous member’s output — a chain. |
| Parallel | All members run at once on the same input. A judge merges their outputs into one answer; without a judge they are returned together. |
| Race | All members run at once; the first to finish wins. Every racer’s cost is still counted, so a budget cap holds. |
| Debate | Members argue over several rounds, each round seeing all prior responses. A judge then reads the debate and writes the final answer. |
The judge is any agent you choose, so a Claude debate can be settled by GPT-4o, or the reverse.
(Workflow agents have a separate consensus merge node — a judge that combines branch outputs. That is a node, not a collaboration mode.)
Constraints
Constraints are per-agent rules that keep an agent from repeating mistakes. Add them on the agent’s Constraints tab, or let the agent learn them: when a run fails, the lesson is distilled into a new constraint automatically. Active constraints are always-on — applied on every run — which makes them distinct from memory, which is recalled by relevance.
For the Support Orchestrator the active rules read like “never promise a refund over $500 without approval,” “Scale-plan customers get a four-hour SLA,” and “keep replies under 150 words.” A blocked run can add its own: “a run was blocked for issuing a $900 refund without approval — gate refunds over $500.”
Promote a run to a skill
When a run goes well, promote it from the Promote to skill dialog. almyty
distills the run — its tool sequence and output — into an
Agent Skills SKILL.md, stored and versioned. From the
Skills tab you can view it, replay it, or delete it. The skill is served over
the Skills gateway and REST, so another agent, or your editor
via @almyty/skills, can call it instead of re-deriving the steps.
A reasoning-only run produces the procedure in prose; a run that called tools lists them in order (“1. Look up order status, 2. Search the knowledge base, …”), so the skill captures the real steps.
Memory
With memory enabled, the agent stores facts, preferences, and context and recalls them on later runs by embedding search. See Memory for the full model.
Context compaction
Long runs can outgrow the model’s context window. Turn on compaction and almyty keeps the run bounded: once it goes over a token budget, the older history is folded into a cached summary while the recent messages are kept verbatim. It runs automatically; there is nothing to watch.
Create an autonomous agent
In the UI: Agents → Create Agent → Autonomous, enter instructions, attach tools, enable memory, add constraints, and configure the verifier panel — all from the form.
A minimal version over the API:
curl -X POST https://api.almyty.com/agents \
-H "Authorization: Bearer $TOKEN" \
-d '{ "name": "Support Orchestrator", "mode": "autonomous",
"instructions": "Triage tickets, draft replies, escalate refunds over $500.",
"toolIds": ["<tool-id>"], "memoryEnabled": true }'Related
- Approvals — pause a run for human sign-off before irreversible actions
- Memory — persistent, embedding-based recall
- Gateways: Skills — serve promoted skills to any client
- Workflow builder — the deterministic alternative