Paroksh is the agent inside Cisely. It does not write code into a repository somewhere and hand you a pull request — it writes the model your software is derived from, and the useful thing to know about it is not what it can do. It is where it stops.
Open the panel from anywhere in Cisely and start talking. There is nothing to install and no key to paste.
What it does
- Draft the business context. You talk, and Paroksh asks what is missing. Out of it come the mission, the beliefs and how strongly you hold them, the strategy, the personas and the stakeholders.
- Turn goals into promises that can be checked. A goal is what someone is trying to achieve; an expectation is the measurable version of it. It writes that version — and tells you when a goal has no measurable version, which is a finding rather than a failure.
- Model the application. Actors, processes, entities, invariants, commands, queries, policies and routes. The backend, the schema, the API and the typed clients are all derived from what it declare.
- Keep the record. Decisions, the reasoning behind them, what was learned and what is still open — written down as it goes and anchored to the thing each one is about.
Where it stops
This is the half worth reading twice. Speed is easy to buy; knowing that nothing consequential happened while you were not looking is not.
Nothing Paroksh writes counts until you activate it. Everything arrives as a draft. You read it, change what is wrong, and activate what you agree with. Until you do, it is a proposal — which is what keeps the model holding what you actually believe rather than what was merely plausible.
It asks in a form, and never more than three things at once. A question with six parts is one form or three rounds of chat. So it sends a form, capped at three questions, because a person answers three carefully and skims twelve.
When Paroksh needs a decision, it is blocked. The request is a dialog you cannot dismiss by clicking past it, and it genuinely cannot proceed until you answer. A prompt a person can wave away leaves an agent hanging with nothing on screen explaining why.
It stops when the reason does not hold. If a piece of work names no expectation it serves — or names one the business never agreed to — that is reported rather than worked around. A blocked task with a clear question is a good outcome. A finished one built on an invented assumption is not.
It acts as you, never as itself. Every write goes through the same permission-checked operations you would use by hand, as the signed-in person. There is no service account and no private door into your data: if you cannot reach something, neither can Paroksh.
It reports what happened, not what it expected. Anything that failed, anything skipped and anything unverified is volunteered without being asked, and never trimmed for brevity.
Where you meet Paroksh
| Beside the business model | Open Paroksh anywhere in Cisely and it can read and propose across the whole context — mission, strategy, personas, expectations, work. |
| In the Workshop, on one project | Bound to the application you are building, next to the nine lenses of the same model. |
Same agent, same identity, same rules. The difference is what is in reach.
Choosing the model underneath
Paroksh is the agent, not the model. You can point it at a provider Cisely runs, or at your own Claude or Codex subscription.
Two things about this surprise people, so they are worth stating plainly:
- It is a session-start setting. The model is chosen when a session begins and cannot be changed under a running one. Change it and the next session picks it up; the status bar always names what the current session is actually running, so "I changed it" and "it changed" never look alike.
- No choice is a valid choice. Leave it unset and the platform picks — the first connected provider's default. That stays correct as the catalogue changes underneath it, which a pinned model does not: a provider can be disconnected and a model can stop being offered.
Running on your own subscription means your provider bills you directly, and that session is outside Cisely's metering.
What it remembers
Nothing. A session ends and everything it was holding goes with it.
What survives is what was written down — which is exactly why the writing down is part of the work rather than an afterthought. A new session begins by reading the last one: what was being attempted, what changed, what blocked it, what was learned, and the next concrete step.
When a conversation grows long enough that quality would start to suffer, Paroksh offers to recharge — write the handover, clear what it is holding, and continue in a fresh session. Take it. The alternative is an agent quietly getting worse while sounding exactly as confident.
Getting a useful first hour
- Tell Paroksh about the business, not the software. Who you serve, what you promise, how you know it worked. The domain model falls out of that; going the other way does not work nearly as well.
- Correct it early and bluntly. A wrong belief left standing propagates into strategies and expectations built on it.
- Read the drafts before activating. The review is the point; skipping it converts a careful tool into a fast one.
- Answer the blocking questions. They block because the answer changes what gets built.
Next: The Workshop, where the same agent sits beside the application you are building.