Platform · Build · The workhorse

Sequential Agents

Every team runs procedures a person shouldn't have to: the same document read, the same fields keyed, the same checks made, hundreds of times a month. The scripts and no-code chains built to absorb that work can't read a document, can't handle an exception, and break silently when a form changes. A Sequential Agent is the procedure rebuilt as a worker: typed inputs, ordered tasks, scoped access — and a full trace on every run.

Build your first agent Start from a template
At a glance
  • Unit of workordered tasks
  • RuntimeLangGraph, streamed live
  • Inputs8 typed kinds, validated
  • Accessleast-privilege, per agent
  • Triggerscron · event · webhook · table
  • Risky writesheld for approval
  • Every runtraced, costed, config-pinned
IN A SOLUTION PACK

In a pack, these agents arrive configured: tasks, scoped access, and triggers already wired.

See Solution Packs →
app.turtlecoworker.com/agents/editor
The agent editor: instructions and configuration tabs on the left, the ordered task workflow docked on the right with the live runtime/token/cost estimate visible
The agent editor: configuration on the left, the ordered task workflow docked on the right.
Why it's built this way

The automation you have
breaks where the work gets real.

RPA clicks where the button used to be. A no-code chain passes fields it cannot read. Both do the happy path — and the happy path was never the expensive part. The expensive part is the invoice that doesn't match, the form that changed on Tuesday, the exception nobody caught for three weeks.

A Sequential Agent is built for exactly that part: it reads documentsinstead of scraping pixels, it recognizes exceptions and routes them to a human instead of keying them anyway, and it cannot fail silently — every run either completes with a trace or stops with one.

Why teams switch

The procedures still done by hand are done by hand because the last automation attempt couldn't survive contact with real inputs. A Sequential Agent is a versioned procedure with judgment: it reads what arrives, follows the steps, and stops to ask when something doesn't fit.

What most AI tools give you
  • RPA that replays clicks — until the form changes and it clicks the wrong thing
  • No-code chains that can't read a PDF, an email body, or a scan
  • Exceptions keyed in anyway, discovered weeks later at close
  • Silent failure: no record of what ran, what it touched, or what it skipped
What Turtle AI Coworker gives you
  • Typed inputs, validated before a run spends a cent
  • An ordered workflow that reads documents and handles exceptions
  • Least-privilege access, enforced at runtime, per agent and per table
  • A config-pinned trace on every run: steps, tool calls, cost
Time to configure
~15 min
From a template to a first successful run. No code, no canvas to wrangle.
Cost per run
~$0.42
Estimated live as you build; every real run metered in Analytics.
Effort to operate
Set & forget
Fires on a schedule, event or webhook. Exceptions come to you; the rest doesn't.
See it work

Twelve jobs. One agent shape.

Pick a job. There are a dozen here and the pattern never changes: typed inputs, ordered tasks, scoped access, a traced result.

A new lead hits your CRM with just a name and an email. You need firmographics, a fit score and a clean row, before a rep ever sees it.

01Takes a typed input

The lead's email and domain, validated on the way in. A malformed row fails fast, not silently.

02Runs ordered tasks

Enrich firmographics → score fit against your ICP → format the row. Each step passes its output to the next.

03Writes back, scoped

Read + Create on your Leads table; Delete stays off, and the write is attributed to the agent.

~30s
per lead, unattended, versus ~8 minutes of manual research.
Anatomy of an agent

Eight surfaces. One reliable worker.

Each one exists because something in hand-built automation breaks without it.

01 · Instructions

The procedure is written down, once, and versioned.

The reason manual procedures rot is that they live in someone's head; the reason scripts rot is that nobody can read what they were supposed to do. An agent's instructions are its operating manual in plain Markdown — the role, the rules, the never-dos — and every run inherits them. Change them and a new immutable config version is cut; every run stays pinned to the version it executed under.

  • Role + instructions in plain language, with {{ inputs }} woven in
  • Temperature, max tokens, timeout: hard behavioral limits per agent
  • Edits cut a new config version; past runs keep theirs
The agent editor, Basic Settings tab: role field, the Markdown instructions editor with an {{ inputs }} token visible, and the temperature / max-tokens / timeout controls
The operating manual: rules the ten-thousandth run still follows
02 · Typed inputs

Bad data fails at the door, not in row 4,000.

Brittle automations don't fail loudly — they ingest a malformed value and produce confident garbage. Every agent declares exactly what a caller must provide: eight input kinds, each with per-type validation, checked before the run spends anything. A run that would have gone wrong never starts.

  • Short & long text, number, URL, select, boolean, date, file
  • Per-type rules: email format, allowed domains, min/max, regex
  • Required inputs reject incomplete calls before they cost a cent
The add-input modal: the eight input type options, a Required toggle, and per-type validation rules (allowed domains on a URL input) filled in
Eight kinds, validated on the way in
03 · Workflow

Ordered tasks, streamed live, on a LangGraph runtime.

The work itself is an ordered list of tasks, each with its own instruction and expected output, each passing its result to the next with {{ params }}. Runs execute on a LangGraph runtime that streams every step as it happens — so 'what is it doing right now' is something you watch, not something you infer from a log afterward.

  • Each task: one instruction, one expected output, one small job
  • Tasks reference run inputs and any earlier task's result
  • A live estimate of runtime, tokens and cost updates as you build
The workflow rail: three ordered tasks each showing instruction and expected output, a {{ params }} reference passing task 1's output into task 2, and the live runtime/token/cost estimate
The workflow: small steps, explicit handoffs, a running estimate
04 · Tools

Hands in your stack — exactly as many as the job needs.

An automation that can reach everything is a liability with a login. Tools are connected once at the org level, then granted per agent with only the scope that job needs. Every call the agent makes goes through the same policy engine that governs the rest of the platform, so 'what can this thing touch' has a checkable answer.

  • 70+ integrations plus any custom REST or MCP tool
  • Scoped auth: read-only where write isn't needed
  • Every call evaluated by the policy engine before it executes
The Tools tab: integrations granted to this agent, each row showing the tool, its auth method and the granted scope
Granted tools: auditable, least-privilege, per agent
05 · Knowledge

It reads your playbooks. It cannot edit them.

Exception handling is where hand-built automation gives up — the script has no idea what 'normal' looks like. An agent grounds its judgment in attached knowledge bases it semantic-searches at run time: your policies, your vendor terms, your playbooks. Knowledge is strictly read-only, so the reference material can never be mutated by the thing consulting it.

  • Files, crawled sites, pasted text, synced Drive/Notion
  • Automatic chunking and embedding — no manual indexing
  • Read-only by construction: grounding without write risk
The Knowledge tab: knowledge bases attached to the agent, each marked read-only, with source counts visible
The reference shelf: searchable, citable, immutable to the agent
06 · Tables

Results land in business data, permission by permission.

The output of a procedure belongs in a system of record, not a chat transcript. Table access is granted per table with four independent permissions — Read, Create, Update, Delete — enforced by the runner at execution time, not by the prompt. Delete stays off unless you turn it on, so a bad run can file wrong rows but can never wipe right ones.

  • Per-table R / C / U / D, enforced at runtime
  • Least-privilege default: Delete off, sources read-only
  • Every write attributed to the agent and traced
The Tables tab: the per-table Read / Create / Update / Delete toggle grid with Delete off on the target table and a reference table set read-only
Four toggles per table, checked at run time
07 · Triggers

It notices the work arriving. Nobody presses Run.

A procedure that waits for a human to start it is still a human's job. Agents fire on their own: a timezone-aware cron schedule, an integration event, a rotatable webhook any system can POST to, a table trigger when a row is created or a field changes, or another agent chaining into this one. Event triggers carry filters, debounce and rate limits, and every firing is logged with its payload and outcome.

  • Schedule: cron with a live next-fires preview, timezone-aware
  • Event · webhook · table · agent-to-agent: the work wakes the worker
  • Per-trigger filters, debounce, rate limits gate what actually fires
The Triggers tab: the trigger type options (schedule, integration event, webhook, table), a cron trigger with its next-fires preview, and an event trigger's filter and debounce settings
Five ways to fire, each one guarded and logged
08 · Governance & audit

Silent failure is not an available mode.

The worst property of brittle automation is that it breaks quietly. Here, every run and every tool call lands in the audit trail — inputs and outputs sanitized, reads and writes classified, pinned to the immutable config version the agent ran under. Consequential writes can be held by policy for a single-use human approval, and a failed step stops the run with a full trace of what happened up to that point.

  • Every run and every tool call logged, sanitized, classified
  • Policy-held writes wait for a single-use approval
  • A failure stops and reports — it never limps on or vanishes
A finished run in the audit trail expanded to its per-tool-call rows: read/write classification, sanitized inputs and outputs, and the pinned config version badge
One run, every call it made, and the config it ran under
One procedure, worked

Invoice intake at a shared-services team, run by the system.

A scenario: a shared-services AP team takes in about 4,000 vendor invoices a month by email. Here is what the runtime does with each one — on its own, the same way, every time. Not a click-path; this is the machine working.

Trigger
An invoice lands in the inbox
An integration trigger fires on the new attachment — filtered to invoice-like files, deduped and rate-limited so a vendor's triple-send doesn't become three runs. The firing is logged with its payload before anything else happens.
Extract
The document is read, not templated
The first task parses the PDF or scan into a strict shape: vendor, amount, currency, due date, PO number, line items. There is no field-mapping template to maintain, so a vendor changing their layout doesn't break intake.
Match
Three-way match against the PO table
The next task checks the invoice against its purchase order and receipt — read-only on both tables. Amount, quantity and vendor must reconcile. The agent's grounding KB holds the team's tolerance rules, so 'close enough' means what your policy says it means.
Write
Clean rows are filed
A matched invoice lands as one structured row in the Invoices table — the agent holds Read + Create + Update there, Delete off, so a bad run can file a wrong row but can never destroy a right one. The write is attributed and traced.
Except
Mismatches go to humans — with the reason
An invoice that fails the match isn't forced through. The agent writes it to the exceptions queue with a short note on exactly what didn't reconcile. The AP team reviews the exceptions, not the thousands that matched.
Hold
The approval email is drafted, then held
For matched invoices the agent drafts the approval email — and the send, an external write, is held by policy at an approval gate. A human releases it with a single-use grant; the decision, the decider and the send all land in the same audit trail as the run.
A live run, trigger to result45s
video: demo-agent-runScreen recording, ~45s: a live run trace streaming step by step — the inbox trigger fires on a new invoice attachment, extracted fields appear, the three-way match runs against the PO table, a clean row lands in Invoices, one mismatch routes to the exceptions queue, and the drafted approval email stops at the approval gate.
The run trace, streaming live: every step as it executes
What you can build

If the job is a repeatable procedure, it's an agent.

Lead enricher

Take an inbound lead, enrich firmographics, score fit, write it to your Leads table.

Invoice extractor

Parse an invoice PDF into vendor, amount and line items, filed straight into a table.

Ticket classifier

Read a support ticket, tag category and priority, route it to the right queue.

Content repurposer

Turn one long-form post into a thread, a newsletter blurb and three social posts.

Contract clause extractor

Pull term, liability and renewal clauses out of a contract into structured fields.

Weekly digest

Summarize the week's pipeline changes and post the digest to Slack every Friday.

The payoff
~15 min
from a template to a first successful run: no code, no canvas-wrangling.
8
typed input kinds, each validated before a run spends anything.
4
table permissions: Read / Create / Update / Delete, enforced at runtime.
100%
of runs traced, costed and pinned to the config version they ran under.
From the live catalog

Built on Sequential Agents.

All templates
Lead Scorer (ICP Fit)
Sequential Agent · Sales

Scores any B2B lead for fit against your Ideal Customer Profile on a 1-100 scale using a fixed, weighted rubric (firmographic, persona, engagement and intent, offer-need fit, minus disqualifiers), then returns a tier (Hot, Warm, Cool, Low, or Disqualified), specific reasons, risks and unknowns, and a recommended next action and channel. Pure standalone: paste your lead details and ICP, get a consistent, readable qualification call. No tools or tables required.

3 tasks4 inputsstandalone
Official · ~2 min
Smart Property Listing Generator
Sequential Agent · Realestate

You are a top-performing real estate copywriter with 15 years of experience. You always highlight unique selling points first. You use market comparable data to justify pricing and create urgency. You write in a persuasive yet honest tone. You never exaggerate square footage or features. You include neighborhood lifestyle benefits, not just property specs. You adapt your writing style per platform: professional for MLS, conversational for social media, visual for Instagram

1 task2 inputsstandalone
Official · ~8 min
Legal Invoice Auditor
Sequential Agent · Legal

Reviews outside counsel invoices line-by-line against billing guidelines, flags excessive hours, block billing, vague descriptions, unauthorized timekeepers, rate violations, and duplicate entries. Calculates recommended adjustments, updates the legal spend tracker in Google Sheets, and emails audit results to the billing partner.

5 tasks3 inputs
Official · ~8 min
Discovery Call Prep
Sequential Agent · Sales

Turns your account and contact context into a focused discovery-call game plan: a briefing that separates facts from inferences, tailored open-ended discovery questions (Situation, Pain and Impact, Decision Process), the objections this specific buyer is likely to raise with honest responses, and a call agenda with the one outcome to drive toward. Pure standalone, no tools or tables required.

3 tasks4 inputsstandalone
Official · ~2 min
SMS and WhatsApp Campaign Copy
Sequential Agent · Sales

Writes a short-form SMS or WhatsApp sequence from your audience and offer: a messaging plan with tone, call to action, and compliance notes, then a ready-to-send sequence with character counts, an A/B variant, send timing, and a built-in opt-out on the first message. Brief, human, and compliant. Pure standalone, no tools or tables required.

2 tasks4 inputsstandalone
Official · ~2 min
Call Notes to CRM Summary
Sequential Agent · Sales

Turns raw call notes or a transcript into a clean, CRM-ready summary in seconds: attendees, a short recap, the prospect's pains and needs, action items each with an owner, buying signals, risks, plus a suggested deal stage, the primary next step, and a paste-ready CRM note. Extracts only what was actually said. Pure standalone, no tools or tables required.

2 tasks2 inputsstandalone
Official · ~2 min
Questions

The details, up front.

How is this different from RPA or a no-code automation chain?
Three ways that matter in production. It reads: documents, emails and attachments are inputs, not obstacles, so a PDF invoice doesn't need a template mapped field-by-field. It handles exceptions: an agent grounded in your playbooks recognizes 'this doesn't match' and routes it to a human instead of keying it anyway. And it cannot fail silently: a form change or a bad payload stops the run with a trace, and every run is logged whether it succeeded or not — there is no mode where it quietly does the wrong thing for three weeks.
What happens when a step fails or the data doesn't match?
The run stops at the failing task and leaves a full trace: which step failed, why, and everything it had done up to that point. Exceptions you anticipate are handled inside the workflow — a task that detects a mismatch writes it to an exceptions queue for a human instead of guessing. Timeouts and token caps you set prevent runaway runs, and retries are visible, not hidden.
How do I control what an agent can touch?
Access is least-privilege by default and enforced at runtime, not in the prompt. Tools are scoped per agent, knowledge bases are read-only, and tables carry four independent permissions (Read / Create / Update / Delete) with Delete off unless enabled. Above that sits the platform policy engine: rules on specific integration functions can allow, deny or require approval on any call, and consequential writes wait for a single-use human approval. See the governance layer for the full model.
Can it run without anyone pressing Run?
Yes — that's the normal mode. Agents fire on a timezone-aware cron schedule, on an integration event, from a webhook, from a table trigger (row created, row updated, field changed), or chained from another agent. Event triggers carry filters, debounce and rate limits, and every firing is logged with its payload and outcome. You can also expose an agent as a rate-limited public link, an API endpoint with a rotatable key, or a Slack command.
Which model does an agent use, and what does a run cost?
Whichever you choose, per agent — OpenAI, Anthropic, Google, Mistral and more, including Azure OpenAI deployments and your own keys. The editor shows a live estimate of runtime, tokens and cost as you compose the workflow, and every real run is metered in Analytics, so a prompt change that inflates spend shows up as a number, not a surprise on the bill.
What can we show an auditor?
Everything. Every run and every tool call is recorded with sanitized inputs and outputs, classified read or write, and pinned to the immutable config version the agent executed under — so 'what was this agent doing, and what was it allowed to do, on March 3rd' is a lookup. Approval decisions, trigger firings and failures land in the same trail.
Next rung on the ladder

One agent is a worker. A team is a pipeline.

Agentic Teams