Context Management · the Concise half of Cisely

One authoritative account of your business, curated by people, read by agents.

Who you serve, what they expect, what you believe and what you have decided to do about it — held in one place your team approves. Every change is kept, every connection can be followed, and every person and agent building for you reads from the same source — so people and agents share the same why behind every what.

Request a demo What makes it authoritative

Who do we serve?: Personas, the situations they act in, and the stakeholders each pairing of the two creates.
What do they expect?: Goals in their own language, the measurable promises that stand in for them, and the metrics that say whether you kept them.
What do we believe?: One mission, the convictions underneath it, and the forces acting on the business.
What are we doing about it?: Strategies, the bets that carry them out, and the products, journeys and stories they become.

The problem

Your business context already exists. It just isn’t authoritative.

It lives in a strategy deck, a persona PDF, a goals spreadsheet, a backlog and the heads of the people who were in the room. None of those know about each other, so each drifts on its own schedule — and nobody can say which one is right.

The reason leaves with the person: Why a piece of work exists survives as folklore: somebody was in the meeting. When they move on, the why goes with them, and the next decision is made without it.
Four documents, four answers: Give an AI agent all of them and it will find the disagreements faster than your team did — then pick one, silently, and build on it.
Gaps get filled with guesses: Where nothing is written down, an agent does what it has seen done most often. That is plausible, it is fast, and it is not your business.
Nobody holds the whole picture: Strategy, product and engineering each keep a slice in their own tool. The links between the slices — the valuable part — live nowhere.

What you curate

Four kinds of context, linked into one graph.

Each is a record with its own history, not a heading in a document. What makes it useful is the links between them: from any piece of work you can walk to the promise it serves, the person it is made to, and the belief underneath.

Who you serve

Personas: The archetypes who act in and around your business. Not only people: organisations, groups, systems and AI agents — and regulators and competitors too, because they hold goals that constrain you.
Situations: Where they act: onboarding, billing, compliance, a support forum. Situations can sit inside one another and follow one another in order.
Stakeholders: A persona in a particular situation — the same owner wants different things in onboarding and in billing — including whose interests come first there.

What they want

Goals: What someone is ultimately reaching for, in their own language: to feel in control, to be free of a worry.
Expectations: The measurable promises that stand in for a goal, held by a stakeholder: “an answer the same day”, not “good support”.
Metrics: How you know whether a promise was kept, with readings recorded over time and every change to the definition kept.

What you believe and decide

Mission and beliefs: One mission, and the convictions about your customers and how you win — each graded assumed, observed or validated.
Strategic forces: Regulations, shifts, competitors, strengths and weaknesses, classified once — so SWOT, PESTEL and Porter are three views of the same facts rather than three decks.
Strategies and initiatives: Choices that cascade from the company down, templates for the kinds of strategy your company writes, and initiatives written as bets that could be wrong.

What you build for it

Products: The durable offerings the business builds, and the situations customers meet them through.
Journeys: The path a stakeholder walks through a product to reach a goal, step by step — including who performs each step.
User stories: The unit of work, told from a stakeholder’s point of view. Every story names the expectation it serves.

What makes it authoritative

Curated like a system of record, not collected like a wiki.

Anyone can write a document. What makes context authoritative is how it gets in, how it changes, and what it refuses.

Nothing counts until a person approves it: Paroksh can draft a mission, beliefs and personas in minutes. Everything arrives as a draft, and only what someone on your team activates becomes the context agents build from.
Every change is kept: Statements are revised whole rather than patched, and each revision is kept. “What did we say our strategy was, last March?” has an answer.
Evidence is part of the record: Beliefs carry how much evidence stands behind them; strategic forces carry their evidence, confidence, severity and horizon. An untested assumption is labelled as one.
Every link runs both ways: From a strategy down to the initiatives that carry it out, or from an initiative back up to the belief it rests on. The why is a link to follow, not a person to find.
Things are retired on purpose: Context is archived when it stops being true, or replaced by a named successor — not left quietly active after everyone has moved on.
It refuses what does not hold: An initiative must carry out a strategy. A promise must say who it is made to, and in which situation. A story cannot be committed until an expectation it serves is live.

Why it matters

One why, shared by every person and every agent.

Teams rarely disagree about what is on the backlog. They drift on why it is there: each person — and now each agent — fills in the reason from whatever they last read. When the why lives in one approved place, everyone building for you works from the same reasons, and their decisions line up without a meeting to line them up.

	Without a single source	With authoritative context
Where the why lives	In decks, tickets and people’s memories.	Linked to the work it explains.
When an agent hits a gap	It guesses — plausibly, and silently.	It reads the approved reason, or stops and asks.
When strategy changes	Every copy of it goes stale at a different speed.	Everyone reads the new version at once.
When two requests conflict	Whoever argues longest wins.	The expectation each one serves decides.
When someone joins	They rebuild the reasoning from scratch.	They inherit it on day one.

What you can finally ask

Questions that used to take a meeting, answered by the context.

Why are we building this?: Follow the story to the expectation it serves, the stakeholder who holds it, and the goal behind it.
What have we delivered and never validated?: Delivered work waits for evidence before it counts as working, so the answer is a list rather than an archaeology project.
Which strategies rest on untested beliefs?: Walk from a strategy to the belief it rests on, and read how much evidence stands behind it.
Do we and our customers believe the same thing?: When a customer’s goal and one of your strategies rest on the same belief, alignment is a fact you can point to.
Which promises does nothing measure?: An expectation with no metric can never be judged. That is worth knowing before the work starts, not after.
What changes if this belief turns out to be wrong?: Every goal and strategy that grew from it is one step away.

How you build it

Start where the knowledge already is.

Not with the mission. Begin with one customer you know well, and let the rest widen out from there.

Describe the business
Tell Paroksh who you serve, what you promise and how you would know it worked. Most of the structure comes back roughly right in minutes.
Correct it, then approve it
The parts Paroksh gets wrong are the parts that carry your real knowledge. Fix them, then activate what you agree with.
Widen from one customer
A second situation for the same persona usually surfaces a second expectation straight away. The mission and beliefs get easier once several goals are written down.
Keep it honest
Grade evidence truthfully, let things fail their checks, archive what stopped being true, and revisit it on a regular cadence.

Every concept on this page is covered in depth in the business context manual.

Already have an agent?

Keep your agent. Connect it to the context.

Connect Claude Code, Codex or another agent to the Cisely MCP server. It reads the same model as your team, and you keep working in your own tools. Nothing to install: add one address and sign in through the browser.

Cisely MCP serverhttps://agents.cisely.ai/mcp

What your agent can read

Who you serve, and what they expect: Personas, stakeholders, goals and expectations: who a change is for.
Why you exist, and what you believe: Mission, beliefs, strategy and metrics: the reason behind the task.
How the system is designed: Entities, commands, policies and routes, without inferring them from code.
A model that improves with use: With your permissions, it can record decisions and propose corrections.

Connect it

Claude Code: claude mcp add --transport http cisely https://agents.cisely.ai/mcp, then /mcp to sign in.
Claude, desktop and web: Settings → Connectors → Add custom connector, paste the URL, and sign in.
Codex: Add a remote MCP server in ~/.codex/config.toml, then codex mcp list to confirm.
Anything else that speaks MCP: Register a remote HTTP MCP server at the URL above and complete the sign-in.

Paroksh or your own agent

Aspect	Paroksh	Your own agent
Where it runs	Inside Cisely	Wherever your agent runs
Sees the screen you are on	Yes	No
The draft-and-activate loop	Built in	Your agent’s own behaviour
Blocking questions, capped ask forms	Built in	Not provided
Session handover and recharge	Built in	Your agent’s own context handling
Model usage bills to	Cisely, or your provider	Your provider

For both, every call runs as the signed-in person, so permissions, tenancy and entitlements apply the same way. You can run both: they read and write the same model. MCP access comes with your account. Full setup is in the docs. Applications you build in the Software Factory publish an MCP server of their own, which is a different server: it exposes the system you shipped, not your context.

Where it goes next

Context your builders and agents can stand on.

Once the context is curated, the Software Factory builds against it, and every piece of engineering work traces back to it. Paroksh reads it as it builds, and the agents you already run can connect to it too.

Request a demo Explore the Software Factory Meet Paroksh