Your AI can write code. Give it the whole business to build with.
The Cynap Harness gives an AI builder the customer’s business memory, connected tools, integrations, codebase, safety boundaries, validation, runtime, and operational evidence—in one environment.
The business is
the build context.
The AI does not begin with an empty prompt. It can inspect the business as it exists now: the nouns people use, how records relate, the software already connected, the rules a process follows, what has run, and what needs attention. That turns a request into a change to a living system—not a new island of logic.
Your AI can write code. Give it the whole business to build with.
The Cynap Harness gives an AI builder the customer’s business memory, connected tools, integrations, codebase, safety boundaries, validation, runtime, and operational evidence—in one environment.
The business is
the build context.
The AI does not begin with an empty prompt. It can inspect the business as it exists now: the nouns people use, how records relate, the software already connected, the rules a process follows, what has run, and what needs attention. That turns a request into a change to a living system—not a new island of logic.
The Harness,
layer by layer.
Business memory
Typed records, schemas, relationships, terminology, operating rules and history. The AI can read what is true now before proposing a change.
The Harness is the environment around the model. It supplies the memory, capabilities, constraints and feedback loop that raw model intelligence cannot supply by itself.
One loop, from request
to running software.
Your builder authors and proves. The owner activates. Building powers never reach the running software.
- 01
Inspect
Read workspace status, tree, files, history, receipts, and drift
- 02
Author
Change customer configuration, source, flows, analytics, and tests
- 03
Prove
Inspect the diff, validate, test, and report a verdict for the exact candidate
- 04
Activate and observe
The owner activates the approved revision; Cynap runs it on its trigger or schedule
Choose what you build around
Build on what your business already knows.
Cynap gives your AI shared business records, operating rules, connected tools and run history, with checks and owner approval before anything goes live.
The same request, three ways: “Every Friday, show customers at risk and draft their follow-ups.”
Cynap
Built around your business workspace. One set of records, rules and history serves every automation, flow and page.
Workflow canvas
Built around workflows. Each one connects to project data and tools.
App builder
Built around an app, with its own data, screens and backend.
| Question | Cynap | Workflow canvas | App builder |
|---|---|---|---|
| Work organised around | Your business workspace | Workflows and projects | Applications and their backends |
| Shared records and context | Typed records, relationships, rules and history | Project tables, connected data and workflow history | App entities, shared APIs and connected data |
| Who builds | Your AI authors the code and configuration | Canvas, AI assistant or an external AI | Built-in AI or your own coding agent |
| Before changes run | Candidate checks, then owner activation | Publish; optional workflow review on Enterprise | App publish; automations updated separately |
| Validation and recovery | Declared checks, tests and revision restore | Evaluations and workflow version restore | Browser tests, test data and version restore |
| Runtime and evidence | Scoped tools, triggers and run evidence | Workflow executions and execution history | Hosted apps, workflows and app logs |
Work organised around
- Cynap
- Your business workspace
- Workflow canvas
- Workflows and projects
- App builder
- Applications and their backends
Shared records and context
- Cynap
- Typed records, relationships, rules and history
- Workflow canvas
- Project tables, connected data and workflow history
- App builder
- App entities, shared APIs and connected data
Who builds
- Cynap
- Your AI authors the code and configuration
- Workflow canvas
- Canvas, AI assistant or an external AI
- App builder
- Built-in AI or your own coding agent
Before changes run
- Cynap
- Candidate checks, then owner activation
- Workflow canvas
- Publish; optional workflow review on Enterprise
- App builder
- App publish; automations updated separately
Validation and recovery
- Cynap
- Declared checks, tests and revision restore
- Workflow canvas
- Evaluations and workflow version restore
- App builder
- Browser tests, test data and version restore
Runtime and evidence
- Cynap
- Scoped tools, triggers and run evidence
- Workflow canvas
- Workflow executions and execution history
- App builder
- Hosted apps, workflows and app logs
| Question | Cynap | Workflow canvas | App builder |
|---|---|---|---|
| Runtime AI choice | Your own provider key, or platform-funded calls | Provider keys or gateway models | Built-in model presets or provider keys |
| Usage charged | Operations; your own AI key adds no Credits | Executions; assistant and runtime AI separately | Build messages and integration activity |
Runtime AI choice
- Cynap
- Your own provider key, or platform-funded calls
- Workflow canvas
- Provider keys or gateway models
- App builder
- Built-in model presets or provider keys
Usage charged
- Cynap
- Operations; your own AI key adds no Credits
- Workflow canvas
- Executions; assistant and runtime AI separately
- App builder
- Build messages and integration activity
Building with your own AI uses your provider account. Running software in Cynap uses Credits for its operations. Model calls on your own key add no Credits. Calls on Cynap’s key cost the provider’s price plus 5%, converted to Credits.
Each category describes how its leading products work. Features vary by product, plan and deployment. Checked 14 October 2026.
The owner–builder
contract remains explicit.
The builder prepares and checks the revision. The owner approves it. Cynap makes that same revision live.
The owner decides what should be true
The builder decides how to make it true
The owner decides what
should be true
One person can hold both roles, but the responsibilities remain distinct.
- 01AuthoringPrepares and checks the revisionBuilder
- 02ApprovalApproves this revisionOwner
- 03ActivationCynap makes the approved revision liveOwnerthenCynap
One person can hold both roles, but the responsibilities remain distinct.
- 01AuthoringPrepares and checks the revisionBuilder
- 02ApprovalApproves this revisionOwner
- 03ActivationCynap makes the approved revision liveOwnerthenCynap
One sentence in.
One governed revision out.
The owner decides what should be true. The builder decides how to make it true.
- 01
Connect the authoring environment
Codex or Claude Code joins the customer’s Harness. Your own AI account uses no Cynap Credits.
- 02
Inspect before authoring
Context, workspace, history and recent runs, before a single edit.
- 03
Create and prove the change
Nothing goes live until the exact revision passes its checks.
Built like software.
Run like infrastructure.
Once activated, Cynap owns the operation. The business keeps the decisions.
- It runs. Cynap handles schedules, triggers, retries, and concurrency toward connected tools. A permitted user can also run the automation on demand.
- It leaves evidence. Every run has an organisation-scoped activity record, failures included. Missing capture remains visible rather than being presented as proof.
- It stays inside its boundary. Runtime receives only the tools, connections, limits, and credentials declared for the activated revision. Consequential actions remain subject to the required human approval.
- It remains changeable and recoverable. A builder returns to source, creates a new revision, proves it, and asks the owner to activate it. An earlier revision remains available to restore.
Built like software.
Run like infrastructure.
Once activated, Cynap owns the operation.
The business keeps the decisions.
It runs. Cynap handles schedules, triggers, retries, and concurrency toward connected tools. A permitted user can also run the automation on demand.
It leaves evidence. Every run has an organisation-scoped activity record, failures included. Missing capture remains visible rather than being presented as proof.
It stays inside its boundary. Runtime receives only the tools, connections, limits, and credentials declared for the activated revision. Consequential actions remain subject to the required human approval.
It remains changeable and recoverable. A builder returns to source, creates a new revision, proves it, and asks the owner to activate it. An earlier revision remains available to restore.
