Questions, answered plainly.

Ordmere is a platform for persistent AI Operators. Each Operator carries one Mission — a recurring business outcome with explicit context, controls and a definition of done.

You describe what needs to happen. Ordmere helps define the Mission, understands the context, identifies the systems and access it needs, and works within the controls you set. It's being built to keep the state of the work over time and surface exceptions when a person is needed.

Yes, of a specific kind. An Operator is a persistent AI worker with one Mission.

You don't assemble or manage a team of agents. You give an Operator an outcome, set its boundaries, and govern the work in Mission Control.

No. Conversation is one way to tell Ordmere what you want. The product itself is an operating layer for recurring work.

A chatbot answers. An Operator keeps the Mission moving.

Those tools are excellent when you know exactly which trigger, steps and integrations to connect.

Ordmere starts somewhere else: the business outcome. It works out the rules, context, systems, permissions, approvals, completion criteria and exceptions with you. You never build a node graph — and you can keep your existing automations for the steps they do well.

You can. The difficult part usually comes after the demo:

• How does it authenticate, and what is it allowed to do?
• How does it remember the state of ongoing work?
• What happens when data is missing, or two systems disagree?
• When should it ask for approval?
• How are duplicate actions prevented?
• How do you know the result actually completed?
• What happens after an API failure — and who maintains it when things change?

Ordmere is being built around exactly those operational problems.

A Mission is a defined, recurring business outcome Ordmere is responsible for operating.

It includes the objective, the context it needs, when it runs, the business rules, the systems and capabilities it uses, its control boundaries, what counts as complete and what happens when work can't finish.

Missions are most useful when work:

• happens repeatedly
• crosses systems
• depends on rules
• needs follow-up or can become overdue
• has exceptions
• sometimes needs approval
• needs evidence that it's complete

If one application already completes the whole job cleanly and reliably, adding Ordmere may add little. Ordmere checks this when you describe a Mission and will tell you.

Ordmere is strongest in the gaps between systems, people and decisions.

No. Many people know the pain before they know the solution. You can start by describing:

• something repetitive
• something people constantly chase
• a process that falls through the cracks
• a recurring report
• systems somebody keeps checking
• a responsibility you wish somebody reliably owned

Ordmere helps shape that into a Mission with you.

That's planned. As Ordmere learns your company's context, it's intended to point out recurring, cross-system work that could become a Mission — and explain why, rather than setting anything up on its own.

Today, the site and setup offer starting points you complete in your own words.

Yes. You can change a Mission in plain language during setup, and Ordmere shows exactly what changed in its definition, systems and controls.

For active Missions, versioning is planned so that changes to rules, permissions or completion criteria are deliberate and visible — never a silent change to a running process.

It depends on the Mission. A narrowly defined Mission may take a few minutes to describe and shape; a complex one may need more company context, systems or approval boundaries.

The goal isn't to complete setup for its own sake. It's the first useful result, as quickly as is responsible.

Because businesses aren't identical. A giant questionnaire either asks irrelevant questions or misses the important ones.

Ordmere asks for the next piece of context only when it changes the Mission — and skips anything it already knows.

No. Company context you add — your website, a policy document, how your teams work — carries over to your next Mission, so it starts from what Ordmere already understands.

Ordmere asks when something is missing or ambiguous, not because every Mission starts from zero.

Before a Mission runs routinely, Ordmere is designed to run it once under supervision. You inspect what it found, what it understood and decided, what it would do, the evidence and whether completion was reached — and correct anything before trusting it with recurring work.

Supervised proof is in development; it's the next stage of the product.

Only within the permissions and controls set for that Mission. Each action is set to happen automatically, to ask first, or never to happen.

Financial and destructive actions are never offered as automatic, and if no rule allows an action, it doesn't happen.

Yes. External messages ask first by default in Work with approval, and some Missions never request permission to send at all — Ordmere drafts, and a person sends or approves.

When Mission Control is available, approvals will arrive in Needs You with the draft attached.

Missions have explicit limits today — items per run, messages per day, retries, amount thresholds that need approval.

Usage and spend limits for external AI and API costs are in development. The principle: financial autonomy always has visible boundaries.

It shouldn't bluff. If information is missing, a rule conflicts, permissions are insufficient or the situation is beyond the Mission's allowed autonomy, Ordmere is designed to stop that action and surface it as a Needs You decision.

You can already see this in setup: conflicting instructions become a decision for you, never a silent choice.

Needs You is where decisions that need a person will go: what happened, why Ordmere stopped, what it recommends, the evidence and what's needed from you.

Instead of monitoring everything Ordmere does, you handle only what needs judgement, approval or information. Needs You is part of Mission Control, which is in development.

Every Mission defines explicit completion criteria when it's set up — for example, “every qualifying order appears exactly once and matches its current state.”

At run time, Ordmere is designed to verify that business state rather than call work finished because an action was attempted. Runtime verification is in development.

The Mission is designed to keep its state. Depending on the failure and the Mission's controls, Ordmere retries where that's safe, waits, or surfaces the exception for a person.

Every Mission already defines what happens when a system is unavailable. A transient failure should never make ongoing work vanish.

That's exactly the cross-system exception Ordmere is built for. A Mission can set which source is authoritative, which differences are acceptable and when to escalate.

When a discrepancy can't safely be resolved automatically, Ordmere is designed to surface it with the evidence from both sides.

It's designed to. Mission History will record meaningful activity — actions, decisions, approvals, exceptions, recovery and outcomes — so you can see what happened and why.

In setup today, every change to a Mission's definition, systems and controls is already tracked and shown. History for running Missions is in development.

Ordmere is being built to work with the systems Missions depend on: email, files, collaboration, CRM, ecommerce, finance, support, analytics, spreadsheets, projects and custom APIs.

The Integrations page shows every system in the catalog with its honest status. Today they work in the setup preview with simulated connections; production connectors are in development, and nothing is shown as available until it is.

No. A Mission requests only the systems and capabilities it needs to finish — and tells you which ones are optional.

Only because a Mission needs to read information or take an approved action inside a system.

Each requested capability comes with its reason (“Read new orders — to find orders over $500”), alongside what Ordmere doesn't need.

Yes. A connection can be removed once no Mission depends on it, and removing a Mission removes only that Mission's access.

If disconnecting would stop an active Mission, Ordmere tells you what's affected first.

No. Connection doesn't mean unrestricted autonomy. Ordmere separates the organization connection, each Mission's access, action controls and approval policy.

A Mission is granted only the capabilities it needs, on the narrowest resource it can justify — one spreadsheet, one channel.

No. You should always be able to see the meaningful actions Ordmere took and the state of the Mission.

Explainability means the rule, the evidence and the result — operational accountability, not a transcript of a model's private reasoning.

Sensitive or consequential actions sit behind approval boundaries. You decide where Ordmere can act on its own and where a person must authorize — and the Mission's own approval rules can't be quietly relaxed.

Mission controls exist to prevent it. The absence of a rule is a denial: when an action falls outside the Mission's boundary, Ordmere fails closed rather than expanding its own authority.

New access is never added silently either — any expansion is shown for your review.

Not in the setup preview: connections are simulated and no credentials exist. Production connections will use each provider's own authorization flow; credentials are kept out of the Mission model entirely.

You don't have to choose a model to create a Mission. Ordmere's job is to use the right underlying capabilities for the work.

The Mission stays the stable thing you manage, even as the AI ecosystem underneath it changes.

Bring Your Own Key: using your own provider credentials for certain underlying AI or API services, so external usage is billed to your provider account directly.

BYOK is planned, where providers support it.

No. What matters is transparency: you should know what external usage applies before you activate a Mission.

$99/month, which includes up to 3 active Missions. Each Mission beyond those included is +$49/month. External AI, API or provider usage may be billed separately where it applies, and complex or higher-scale deployments may need a custom plan.

Before any of that, your first Mission is proven under supervision with a $0 platform fee, and you decide whether it's worth activating. Supervised proofs and billing are in development; your price is always shown before you activate.

Ordmere carrying up to 3 active Missions: operating the recurring work, controls and approvals, decisions that need you, state and history, verified outcomes with evidence, and monitoring and recovery around each one.

You pay for the responsibility, not the mechanics — there are no seats, per-task charges or credits. Parts of the running product are in development; the Pricing page shows where Ordmere is today.

The base price includes up to 3 active Missions. Each recurring responsibility you activate beyond those included is +$49/month. For example, Customer Onboarding, Revenue Pipeline and a Leadership Brief can all sit inside the base price.

Seats, steps, tasks and the systems a Mission touches don't change the price. Ordmere earns each additional Mission the way it earned the first.

The proof is free; ongoing operation isn't. Your first Mission is proven under supervision with a $0 Ordmere platform fee, for up to 14 calendar days from the first supervised proof run.

It's a proof window, not a software trial. The clock doesn't start when you sign up, describe the Mission or connect a system — only when Ordmere starts the supervised proof run.

The proof can end sooner: when the agreed outcome is verified, if the Mission turns out not to be supportable yet, if the access or information it needs isn't available, or if continuing would exceed the agreed safety or usage limits. It isn't meant to run as a live production process.

Supervised proofs are in development; this is how they're designed to work.

Once the proof has produced a verified result, you decide whether to activate it. If you do, $99/month begins and includes up to 3 active Missions. If you don't, nothing is charged.

Supervised proofs and billing are in development — nobody is charged during the preview.

Because you shouldn't pay for a promise that has only been configured. Ordmere should show useful work before asking you to rely on it.

Then don't activate it. You pay for Missions you choose to keep running, not for trying. If a Mission isn't supportable yet, Ordmere says so rather than stretching the proof.

There’s one free proof per company or organization, for one Mission, unless we agree otherwise. After that, $99/month includes up to 3 active Missions; Missions beyond that use the additional-Mission price.

No. External services can have their own usage costs — during the proof and after — and they're kept separate from Ordmere's fee rather than hidden in it.

Where they apply, Ordmere is designed to show what to expect and the limits you approve before the proof and before activation. Estimates are in development.

No. Applicable external usage is disclosed before activation, and usage limits are part of a Mission's controls where supported. No opaque token bundles, no vague credits, no surprise bill.

No. A Mission's controls set its limits before it runs, and anything financial always asks first. Spend limits for external usage are in development.

Yes. You decide whether a Mission stays active.

Complex or higher-scale deployments may require a custom plan. Tell us about the work when you describe the Mission, and we'll agree the right plan with you.

That isn't the goal. Ordmere takes ownership of recurring operational work that consumes attention unnecessarily.

Often that means someone who spends their day checking, chasing and moving information can spend it on work that needs judgement, relationships or expertise.

Not the most ambitious process in the company. Start with something recurring, measurable, annoying and bounded — useful enough that you'll notice when it disappears.

Give Ordmere one real responsibility. Let it earn another.

Give it something your business repeatedly has to remember. Then watch what happens.