Agents In Cessy

Cessy supports agents at two different layers.

LayerMCP serverMain job
Design-timeDesign MCPHelp builders inspect, validate, change, preview, and publish app design.
RuntimeRuntime MCPHelp users operate a published app through generated commands, projections, channels, users, DMs, and page refresh.

This separation is important. A runtime support agent should not need design-time mutation tools. A builder agent should not assume runtime state without reading the published contracts and environment.

Design-time agent loop

A good builder agent starts with:

get_app
get_domain_model
list_errors
get_reference

Then it proposes a workspace plan, makes scoped edits, validates, and summarizes runtime impact before promotion.

Use Connect Design MCP before asking Claude, Codex, ChatGPT, or ces to help with builder work.

Runtime agent loop

A runtime agent should:

  1. read relevant projections
  2. open or use the appropriate channel
  3. explain intended user-visible action
  4. execute generated command tools
  5. verify resulting projection state
  6. post a concise channel update

See Runtime MCP.

Safety rule

Give agents the narrowest MCP authority that matches the job:

  • read-only Design MCP for discovery and review
  • full Design MCP for trusted design mutation
  • Runtime MCP for published app operation
  • API keys only for automation that cannot use OAuth

When a task crosses layers, make the handoff explicit.