Paroksh is the agent inside Cisely. They do not write code into a repository somewhere and hand you a pull request — they write the model your software is derived from, and the useful thing to know about them is not what they can do. It is where they stop.
Open the panel from anywhere in Cisely and start talking. There is nothing to install and no key to paste.
What they do
- Draft the business context. You talk; they ask 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. They write that version — and tell 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 they declare.
- Keep the record. Decisions, the reasoning behind them, what was learned and what is still open — written down as they go and anchored to the thing they are about.
Where they stop
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 they write 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.
They ask as a form, and never more than three things at once. A question with six parts is one form or three rounds of chat. So they send a form, and it is capped at three questions, because a person answers three carefully and skims twelve.
When they need a decision, they are blocked. The request is a dialog you cannot dismiss by clicking past it, and they genuinely cannot proceed until you answer. A prompt a person can wave away leaves an agent hanging with nothing on screen explaining why.
They stop 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.
They act as you, never as themselves. 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 they.
They report what happened, not what they expected. Anything that failed, anything skipped and anything unverified is volunteered without being asked, and never trimmed for brevity.
Where you meet them
| Beside the business model | Open them anywhere in Cisely and they 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 eight views 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 them 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 they remember
Nothing. A session ends and everything they were 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 they are 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 them 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 them 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 are blocking because the answer changes what gets built.
Next: The Workshop, where the same agent sits beside the application you are building.