From intent to result.
No prompt engineering, no babysitting. You describe the outcome; entities plan, execute, and verify — and wait for your sign-off at the gates you define.
Request AccessConnect your stack
Link Search Console, GA4, WordPress, and Slack in minutes. Orchestror reads your real data.
Chat with your entities
Type one command and watch the analysis stream live — every tool call visible in the thread.
Entities ship. You approve.
The full pipeline runs — research, writing, publishing — and pauses for your sign-off.
Plan. Execute. Verify.
Then you approve.
Every request runs the same loop: the orchestrator plans and delegates, specialists execute with every tool call visible in the thread, the verification layer checks each claim against the database. Anything that touches production pauses at your approval gate. Every action lands in the client's changelog, so next week's recommendations know what this week already shipped.
gsc-opportunities1,240 queries analyzedspawn: seo-analystscoring 14 candidatesspawn: content-writerrefreshing /ac-repair-cost/Your tokens buy thinking,
not busywork.
When an entity needs your GSC data, it doesn't read a thousand-row export. A deterministic tool pulls the data and crunches the numbers in plain code, then hands back the scored shortlist — the model reasons over answers, not raw dumps. Crawls, backlinks, analytics: every data-heavy job works this way, so the same run costs a fraction in tokens, every time. Now multiply by ten clients on weekly schedules — that's the difference between a tool you meter and a platform you forget about.
See the loop run on your clients.
Request AccessModel-agnostic
by design.
An entity is its instructions, its skills, and its client context — not the model underneath. Every entity and every workflow picks its runner: Claude today, Codex today, and when the next great model ships, it plugs in as one more option. The full roster — 79 skills, 31 agents — stays in sync across every runner automatically. No rewrites, no migration, no lock-in.
site-auditorchestrorclaudecontent-writerspecialistclaudesearch-query-analystspecialistcodex ⌄Spend where it counts,
not where it's easy.
An orchestrator doesn't run every sub-task on the same brain. Complex reasoning — diagnosing a ranking drop, weighing a risky migration — gets bumped to a stronger tier for that one delegation. Mechanical work — reformatting a table, rewriting boilerplate — runs on a lighter, faster one. You get sharper judgment on the hard calls and lower spend on the easy ones, in the same run, without touching a setting.
spawn: editorconflicting facts, judgment callspawn: content-writeron-brand draftspawn: internal-linkingmechanical rewriteOne platform,
every frontier model.
Orchestror works across vendors. Run Anthropic's Claude on one entity and OpenAI's Codex on another, compare what performs, and keep the winner. Gemini is next in line — your agency rides the frontier, whoever ships it.
Runs on your own
provider accounts.
The full feature set runs on APIs you connect: Google for search and analytics data, crawling and SERP providers for research, ad platforms, image generation, and email for report delivery. Your keys are stored encrypted inside your dedicated instance, usage is billed by each provider directly to you — no markup, no middleman between you and your data.
Straight answers
Which models can entities run on?
Today: Claude and Codex, selectable per entity, per skill, and per workflow. Entities are defined by their instructions, tools, and client context — not by the model underneath — so the runner is a setting, not an architecture decision.
Can I switch models later?
Anytime, per entity. Run your orchestrators on one model and a specific specialist on another, compare, and keep what performs. Nothing else changes — same skills, same context, same approval gates.
Which provider APIs do I need?
It depends on the features you use. SEO needs your Google account (GSC, GA4); research and competitive work use your SERP, crawling, and backlink data providers; publishing needs per-site WordPress credentials; visuals use an image-generation key; reports use SMTP. We walk you through all of it during onboarding.
Who pays for API usage?
Each provider bills you directly on your own account — no markup, no reselling. Your search data and your usage stay between you and your providers.
Doesn’t running entities burn through tokens?
Less than you’d think. Data-heavy work — pulling GSC exports, crawling pages, crunching backlink profiles — runs in plain code, and only the computed result reaches the model. Your tokens pay for reasoning and writing, not for re-reading the same thousand rows on every run. The same audit that costs a browser agent ~200,000 tokens costs an entity about 1,500.
Does every sub-agent run on the same model?
Only if you want it to. An orchestrator can bump a single hard delegation to a stronger tier — or drop routine work to a lighter one — without changing the entity’s default. It’s opt-in per call; leave it alone and everything runs exactly as pinned.
What happens when a new model ships?
It gets added as a runner and shows up as one more option in the selector. Your entities, workflows, and client context carry over untouched — you just flip the switch where it helps.
Stop Prompting.
Start Orchestrating.
Tell us about your operation. We'll walk you through the platform, agree on pricing, and hand you the keys to your own dedicated instance.