How G8 works.

G8 is a process-to-execution layer. You describe a process the way you would explain it to a new teammate; G8 compiles it into an inspectable blueprint, binds it to a contract of what it may and may not do, lets you watch it run in simulation, and only then executes it for real — with humans kept on the risky steps and a monitor over every run.

The whole product follows one backbone:

Everything below maps to a stage of that backbone or a building block that plugs into it.

From an empty workspace to a live automation in five moves:

• Describe the process in natural language — roles, hand-offs, tools, approvals, and outputs.
• Review the generated blueprint: the compiled steps, risk level, and automation level.
• Set the contract — which actions are allowed, blocked, or require approval.
• Run a simulation to see the dry-run preview before anything touches a real system.
• Activate and pick a trigger (schedule, webhook, or manual), then watch it in the monitor.

New workspaces start in onboarding, which walks you to your first simulated run before activation.

A process is your intent in words. You are not drawing a diagram or wiring nodes — you write what should happen, who is involved, which tools are touched, where a human should sign off, and what the result looks like.

Good process descriptions are specific about edges: what counts as success, what to do on failure, and which steps are sensitive enough to need a person.

G8 turns the process into a blueprint — an ordered set of steps with a summary, a riskLevel, and an automationLevel. Each step has a type (for example an HTTP call or a message) and may be marked as requiring approval.

The blueprint is the thing you read and correct. It is honest about what the automation will actually do, so review here rather than after a live run.

Every flow carries an explicit contract. It is the difference between an agent that might behave and one that is bounded.

• Allowed actions — what the flow may do.
• Blocked actions — what it must never do, even if a step suggests it.
• Data scope — which data the flow may read or write.
• Approval rules — which steps pause for a human.
• Error policy — what happens when a step fails.

Contracts are visible in the workspace as allow / block / approval chips, so the boundary is never hidden in code.

Simulation runs the flow end to end without touching any real system. You see the steps, the order, and the expected output as a preview. Nothing is sent, posted, or written.

This is simulation-first by design: a flow earns its way to a live run by passing a dry run you have actually looked at.

An execution is one run of a flow. It carries a mode (live or simulation), the trigger that started it, a status, and a list of steps — each with its own status, duration, and any error.

Live executions run with your workspace’s own AI key and connections, and pause at any approval gate the contract defines. Runs can be made idempotent so a retried trigger does not double-fire.

The monitor is the operating view. It rolls up run volume, success rate, errors, and how many runs are waiting on a human, and lets you drill into any single execution and its steps.

Insights extends this with longer-range trends — run volume over time and error breakdowns — so you can iterate on a flow with evidence.

Connectors are how a flow reaches the outside world. They are configured per workspace and governed by each flow’s contract.

• HTTP — call any REST endpoint.
• Telegram — send messages and notifications.
• Email — send mail from a step.
• Slack — post into channels.

Connections can be tested before they are used in a live run, so a bad credential surfaces in setup rather than mid-execution.

A trigger decides when a flow runs. G8 supports three:

• Schedule — run on a recurring cadence, driven by the platform's cron tick.
• Webhook — run when an inbound request hits the flow's URL, guarded by a per-flow secret.
• Manual — run by hand from the workspace, including a one-off simulation.

API and MCP callers can also start a run programmatically — see API & MCP.

An approval gate pauses a live run before a sensitive step and waits for a human decision. Approve and the run continues from where it left off; reject and it stops.

Gates are declared in the contract and on individual blueprint steps (requiresApproval). The monitor shows exactly which runs are waiting, and a run can sit paused without losing its step state.

Automations turn one-off flows into a standing capability. Rules react to events and run flows without anyone pressing a button, and the agents library gives you reusable, contract-bound building blocks to compose with.

Because automated triggers can fire under load, runs support idempotency keys and single-flight execution so the same event does not produce duplicate runs.

G8 is programmable. Authenticate every request with an API key as a Bearer token, then use the REST API under /api/v1 or the MCP-style tool endpoint at POST /api/mcp. A missing or invalid key returns 401.

List the flows in your workspace:

curl https://your-g8-domain.com/api/v1/flows \
  -H "Authorization: Bearer g8_live_xxxxxxxxxxxxxxxxxxxxxxxx"

Keys carry scopes — flows:read, flows:run, executions:read, and mcp — and are shown to you exactly once at creation. The full developer reference, with run and execution examples and the MCP tool catalog, lives on the developers page. Create and manage keys from your developer console.

Plan tiers gate capacity and capability per workspace. Each tier carries its own entitlements and limits, enforced across the workspace, and moving between tiers goes through an activation and payment request.

See pricing for the current tiers and what each one includes.