Questions, answered plainly.

Ziggyy is a platform for running Missions — recurring business outcomes that need information, actions and decisions across more than one system.

You describe what needs to happen. Ziggyy 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.

AI can be part of how Ziggyy gets work done, but Ziggyy is designed around the Mission, not the agent.

You shouldn't have to choose, configure or manage a collection of AI employees. Your concern is the outcome; how the work is coordinated underneath it is Ziggyy's job.

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

A chatbot answers. A Mission continues.

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

Ziggyy 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?

Ziggyy is being built around exactly those operational problems.

A Mission is a defined, recurring business outcome Ziggyy 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 Ziggyy may add little. Ziggyy checks this when you describe a Mission and will tell you.

Ziggyy 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

Ziggyy helps shape that into a Mission with you.

That's planned. As Ziggyy 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 Ziggyy 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.

Ziggyy 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 Ziggyy already understands.

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

Before a Mission runs routinely, Ziggyy 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 Supervised mode, and some Missions never request permission to send at all — Ziggyy 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, Ziggyy 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 Ziggyy stopped, what it recommends, the evidence and what's needed from you.

Instead of monitoring everything Ziggyy 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, Ziggyy 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, Ziggyy 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 Ziggyy 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, Ziggyy 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.

Ziggyy 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 Ziggyy 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, Ziggyy tells you what's affected first.

No. Connection doesn't mean unrestricted autonomy. Ziggyy 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 Ziggyy 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 Ziggyy 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, Ziggyy 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. Ziggyy'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 your first active Mission. Each additional active Mission 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.

Ziggyy carrying your first active Mission: operating the recurring work, its controls and approvals, Needs You for exceptions and decisions, the Mission's state and history, verified outcomes with evidence, and monitoring and recovery.

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 Ziggyy is today.

Each recurring responsibility you activate beyond the first is an additional active Mission, at +$49/month. For example, tracking Amazon orders in a sheet and following up overdue invoices are two Missions.

Seats, steps, tasks and the systems a Mission touches don't change the price. Ziggyy 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 Ziggyy 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 Ziggyy 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 the Mission. If you do, $99/month begins for your first active Mission. 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. Ziggyy 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, Ziggyy 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, each Mission you activate is part of the monthly price.

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

Where they apply, Ziggyy 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. Ziggyy 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 Ziggyy one real responsibility. Let it earn another.

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