Swift IdeasAI agents & automation
Agents that do the work and ask before they act.
We build agents and automations that read your data, draft the next action and wait for a named person to approve anything irreversible. Each one gets a narrow set of tools, a log of everything it did and tests that fail when it drifts. SwiftQMS is built this way: it drafts the document, and a named person reviews and approves it.
What clients arrive with
- We built an agent in a weekend and it does something different every run.
- Our team copies data between four tools to keep one process moving.
- We will not let an AI send anything to a customer without a person seeing it first.
- Nobody can tell us what the automation did last Tuesday, or why.
- It works until an upstream format changes, then it fails silently.
What you get
- A narrow tool surface
- The agent reads and writes through an interface we define, never the raw database. Every action it can take is listed in one file, and each permission is as narrow as the job needs.
- An approval queue
- Proposals land in a dashboard inbox with the evidence behind them. Anything that sends, pays, publishes or deletes waits for a person, and the approval is recorded against their name.
- Scheduled loops with health checks
- Crons and scheduled agent runs, each with a check that raises an alert when a loop stops producing. Holdrate refreshes subscribed workspaces every hour, and a failed refresh leaves a stale-report warning until a retry succeeds.
- An append-only run log
- Every proposal, approval, rejection and outcome is written once and never edited, so you can answer what happened last Tuesday, and why, in one query.
- Evals from real runs
- Recorded inputs from production become the test set. Tests are named for what would break, so a failure reads as a sentence, not a stack trace.
- Failure handling
- Idempotent writes, bounded retries and explicit dead ends. A failed step leaves a visible record and a safe state, not a half-finished action.
- A runbook your team can follow
- How to pause a loop, replay a run, rotate a key and change a prompt, written for the person on call rather than the person who built it.
How the work runs
Map the loop
We walk the current process end to end, mark every step where a wrong action costs money or trust, and agree which steps the agent may take alone.
Build the rails before the model
Tools, permissions, the approval queue and the run log come first. The model call goes in last and runs against recorded inputs before it sees live ones.
Shadow run
The agent proposes while your team works as before. We compare its proposals with what people actually did and fix the gaps before anything is switched on.
Switch on and hand over
Approvals go live in production, the morning health check starts, and the runbook moves into your repo. A loop is finished when it has produced for a week without a message from us.
How engagements start
- Start with one loop: a process map, a risk map and a working agent on your recorded data before any live access.
- Prototype to production in 4–8 weeks for a single loop with approvals, logging and health checks.
- Retained iteration afterwards: we read the run log with you and add loops one at a time.
- You work directly with the two founders. Our own agent tooling does repetitive implementation, always under our review.
Built with
The work behind it
Questions, answered
Something else on your mind? hello@swiftideas.com
Will the agent act without a human?
Only where you decide a mistake is cheap and reversible. By default anything that sends, pays, publishes or deletes goes through an approval queue. SwiftQMS, for example, drafts documents but never approves one: the reviewer and approver fields are left blank for a named person.
Which model do you use?
The cheapest one that passes the evals for that step. We keep providers behind one interface, so a switch is a configuration change plus an eval run, not a rewrite.
What happens when it gets something wrong?
The action is logged, visible and, wherever possible, reversible. The failing case is added to the test set so the same mistake fails a test before it can reach production again.
Can it work with the tools we already use?
If the tool has an API, a webhook or a reliable export, usually yes. If there is no safe integration path, we tell you in the first week rather than building around it.
How do you stop running costs creeping up?
Every model call records its token usage, and each workspace has a hard daily limit. SwiftQMS, for example, caps drafts per organisation per day and refuses a request if it cannot check the count.
Who owns the code and prompts?
You do. The repo, prompts, eval fixtures and runbook live in your organisation's accounts from the first commit.