Pre-release · accepting design partners

From terminal prototype to agent service.

Compose models, tools, skills, memory, workflows and runtime policy in files you can review. Debug the agent in the terminal, then serve the same configuration over MCP inside infrastructure you control.

Apply for early access Explore the stack

One configuration directory. The same kernel. Two ways to run it.

modelper agent

toolsbuilt-in + connected

skillson demand

memoryprovider

Clarvis agent kernel

◇ runtime policyboundaries attached

Clarvis Codeterminal

Clarvis Serverservice boundary

✓ one agent assembledready in Code + Server

reviewable configuration◆model choice◆runtime guardrails◆replaceable memory◆product service◆decision history

The handoff problem

The prototype works. Then it has to become infrastructure.

A useful agent is more than a prompt and a model. It is the permissions it does not answer for itself, the tools it may call, what it remembers, how it plans, who can run it and what remains after a run. Rebuilding those decisions when you move from a local session to a service is where the prototype starts to drift.

Local prompt: Versioned agent profile
Implicit access: Runtime permissions
Chat history: Readable memory + trace
One-off script: Authenticated MCP service

One stack, three moves

Build the behavior. Keep the controls.

Compose

Choose a model per role. Add reusable knowledge, integrations and replaceable capabilities while keeping every piece understandable on its own.

Explore extensions

Govern

Put permissions, command policy, workspace isolation, plan approval and task budgets in the runtime. A model can request an action; it cannot approve its own request. Command policy and isolation are workspace settings, so the workspace itself is part of the trust boundary.

Explore runtime controls

Deploy

Run the agent interactively in Clarvis Code, or place the same configured behavior behind Clarvis Server. Credentials stay with the environment that operates it.

Explore Clarvis Server

A runtime decision, replayed

The boundary did not ask the model to behave.

In this recorded run, the agent attempted work outside its workspace. The runtime refused the unsafe path, the agent adapted and completed the task inside the boundary.

request→interpret→boundary→decision→record

The boundary did not stop the task. It decided where the task could happen.

◆Clarvis ·agent run ·boundary active ·policy active

✗Use a dependency from outside the workspaceUse an external dependency

Refused by the active workspace policyOutside the active boundary

✓Inspect the safe alternatives already availableInspect safe alternatives

✗Reach beyond the workspace boundaryCross the workspace boundary

Refused by workspace isolationStopped by isolation

✓Prepare the dependency inside the workspacePrepare it inside the workspace

The safer path is accepted

✓Complete verification inside the boundaryComplete the task inside

The task completes without weakening policy

runtime boundary activedecisions stay with the run

Reconstructed at decision level from a real Clarvis trace. No commands, source code or project paths are shown.

The deployable artifact

Ship the agent you already tested.

Roles, runtime choices, reusable knowledge and extensions travel together as one reviewable configuration. Clarvis Code uses it for close, interactive iteration. Clarvis Server runs the same kernel on the same configuration, with the deployment posture made explicit: confirmations are answered by policy instead of a person, and memory is enabled per container.

See the server boundary

Agent configuration

Agent roles Runtime choices Reusable knowledge Extensions

kernelone execution contract

Clarvis Codeclose iteration · human present

Clarvis Serverservice boundary · product access

FilesAgents, skills, plans and default memory stay readable.

RuntimePolicy is evaluated outside the model call.

ProvidersModels, memory and plans are replaceable seams.

TraceEach run leaves a local, inspectable record.

Where it fits

A coding agent, an internal workflow, or part of your product.

Your terminal agent

Give each role its own model, grants and instructions. Delegate bounded work, review plans and keep the resulting knowledge in the repository.

Explore Clarvis Code

Repeatable engineering workflows

Fan work out to isolated leader runs with real concurrency and token ceilings, then keep the manager reachable while the work is in flight.

Explore workflows

An agent inside your product

Move the behavior you tested locally behind a narrow service boundary, with caller access and operating policy kept under your control.

Explore the service

Where this actually is

Real system. Pre-release product.

The stack runs and is under active test, but it is not publicly released yet. I am looking for a small number of teams willing to use it on real work and shape the path to the first release.

Direct access to the person building the stack.
A deployment and feedback rhythm agreed together.
Influence over the product while its boundaries are still movable.

Design partners

Bring a workflow you actually care about.

Tell me what the agent would touch, what it must never do and where it needs to run. That is enough to start a useful conversation.

Apply for early access hello@clarvis.dev