Questions
Common questions about Cisely.
Clear answers about what the platform does, how agents are governed, what you own and what is still evolving.
What this actually is
The questions that decide whether to keep reading.
- Is this a code generator?
- It generates a backend, a schema and its migrations, an API and its contracts, and typed clients — but that is the last stage, not the product. The point is that what it generates is derived from the same model your mission, expectations and strategy live in, so the software cannot drift from what it was for.
- What is the difference between Concise and Precise?
- Concise is the business context: who you serve, what you intend, what you promise, and how you will know the promise was kept. Precise is the application that answers that intent, and everything from a validated model through generated software to a running, addressable service. Neither is worth much alone — context nobody builds against is shelfware, and software built against unverified context is the problem the platform exists to solve.
- Do I have to build in Cisely to use it?
- No. If you already have an agent and a workflow you like, connect it over MCP and keep building where you build today — it reads and writes your business and system model as you, under your permissions, so it starts every session knowing who you serve and what they expect. MCP access comes with any account; your subscription tier sets the rate limits.
- Is this only for large organisations?
- No, and the properties that sound enterprise are the reason. Isolation, authorization, validated input, an audit trail and derived migrations fall out of the description rather than being built, so a team of four ships with the floor that normally needs a platform group — which is the same floor a bank gets. What changes with size is how much of the business you have modelled, not which properties the system comes with.
- Do I have to read generated code to stay in control?
- No. You direct and judge; the agent builds. The Workshop gives you eight views of the model — tables, operations, architecture, flows, contracts, coverage and the running app — and Source is there when you want it, not because you need it.
- Who is this for?
- People who hold a clear vision and want to direct it themselves, whether that is a founder turning a conviction into a company or an architect inside a large organisation who can see the whole system before it exists. It is not for handing over the vision and hoping.
Working with the agent
What Paroksh can do on its own, and where it has to stop.
- What can the agent change without asking me?
- The approval requirement belongs to the operation rather than to the agent, so it cannot be escaped by a different caller. Risk is graded: an additive, high-frequency action such as recording a measurement proceeds unattended, a consequential state change needs a confirmation, and a destructive one can require two people. When Paroksh needs a decision the request is modal, cannot be dismissed, and the agent is genuinely blocked until you answer.
- If the AI writes it, how is any of it deterministic?
- Because the agent does not write the system. It authors a model, and a compiler derives the backend, schema, migrations, contracts and clients from that model — the same model producing the same system every time. What you review is a declaration you can hold in your head rather than a diff of thousands of generated lines, and a suggestion that is wrong can only be wrong in ways the language can express.
- Does anything the agent drafts count straight away?
- No. Everything it drafts arrives as a draft. You read it, change what is wrong, and activate what you agree with — so the model holds what you actually believe rather than what was plausible. Every write it performs is done as you, through the same permission-checked operations you would use yourself.
- What happens between sessions?
- The agent does not persist; the work journal does. Decisions, memories, lessons, sessions, checkpoints and runbooks anchor to the same nodes the rest of the model uses, so a new session starts by reading what the last one concluded rather than rediscovering it.
Running what you build
Where it lives, what we operate, and what we do not promise yet.
- Where does the application actually run?
- On managed infrastructure we provision per application: its own database with separate owning and request-path roles, its own event-bus and cache namespaces, its own buckets, a dedicated API gateway behind the shared edge, and certificates issued and renewed for every host. You do not assemble or operate any of it. Between requesting a publish and the application serving there are no operator steps.
- How are we isolated from your other customers?
- That is two questions and they have different answers. Between applications, the platform separates you: a separate physical database, credential-scoped event-bus and cache namespaces, separate buckets, a separate compute namespace. Inside your application, your own customers are separated by row-level security generated from the isolation axes your model declares. Physical names are allocated by the platform from a durable identifier, so no project name can collide with or be used to guess at another customer’s resources.
- What uptime or scale do you commit to?
- None yet, and we would rather say so than publish a number we cannot stand behind. The path from model to running application is built and demonstrated end to end, but the packaging around it — plan, price, placement and any service commitment — is still being settled. If you need a contractual guarantee today, that is a conversation to have with us directly rather than a claim to read off a page.
- Can we use our own domain?
- Yes. Every application keeps its durable platform host, and a custom domain layers on top of it, so branding never becomes an identity change. You point a DNS record at the edge and certificates are issued and renewed automatically.
Ownership, exit and review
The questions a procurement or security review will ask.
- Who owns the code, and can we leave?
- You do, and yes. Initialising a project adds no git remote and stores no git credential — your origin is entirely yours. Generated code is delivered to a branch of your own repository. What you end up with is an ordinary production application on standards-based artifacts, with no runtime of ours to keep in your stack.
- How much hand-written code ends up in the system?
- Imperative code lives only in declared seams, which means it can be counted rather than estimated. In the platform’s own reference application those seams are roughly one percent of what the model generates. The number matters less than the fact that it is knowable.
- How do we know it works?
- The toolchain derives one obligation per falsifiable statement the model makes about runtime behaviour — every guard, policy, validation rule, typed error and isolation axis — and reports how many have evidence behind them, which single constraint is binding, and what has been waived, by whom, until when. It also distinguishes what static analysis showed from what ran in memory from what was proven against a real deployed stack, and refuses to call tenant isolation proven until the last of those exists. We do not publish the scores: they measure how far a verification programme has got rather than how good a product is. Ask in a review and we will walk you through the real report, including the empty parts.
- Does authoring depend on you being up?
- No. Local validation runs with no account and no network, so the loop you spend your day in does not depend on us being reachable. Building, generation and deployment do run on the platform.
What to expect
The questions we would ask if we were the ones signing up.
- How finished is it?
- Cisely is built in Cisely — its own purpose, strategy, product model and the software behind it all live in the substrate. That is the only honest test of a platform like this, and it means we meet whatever does not work before you do. It also keeps the loop back short: an agent that hits a wall can file a support ticket itself, structured as the gap it hit — what it expected, what happened, and what that blocked — so a problem reaches us without waiting for somebody to notice and write an email.
- What happens when I change my mind?
- Change the model and everything derived from it follows. A rename is made once. Schema changes are derived by comparing the model with the database rather than hand-written, and API contracts stay compatible with clients already deployed.
- Does this replace our existing tools?
- Not on our say-so. It covers a lot of ground that project tracking, documentation and architecture tools cover today, but whether it replaces any of them depends on your scope and your integrations. Anyone who tells you otherwise before seeing your setup is guessing.
Something here not answered?
The enterprise door on the way in reaches a person, not a queue. Ask the awkward version of the question — it is the one worth our time and yours.