Ways to control MASAIC
Three ways to drive your workspace: the web console, an AI coding agent over MCP, or the masaic CLI — what each one is best at, and how to mix them.
Everything in MASAIC — agents, models, prompts, skills, tests, automations — can be driven three different ways. They all talk to the same workspace and the same data, so nothing is locked to the tool you started in.
| Way in | You work by | Best for |
|---|---|---|
| Web console | clicking through the workspace in your browser | learning the product, reviewing conversations, one-off changes, anything visual |
| AI coding agent over MCP | asking in plain language inside Claude Code, Codex, Cursor, Windsurf, or Claude Desktop | "create an agent like the support one but for billing", bulk edits, exploring without learning a command |
masaic CLI | running commands, and keeping agent definitions as YAML files | repeatable changes, review-before-ship, CI pipelines, scripting |
Pick one to start with. Most teams end up using all three: the console to look at things, a coding agent to make changes by describing them, and the CLI when a change should be reviewed and repeatable.
Web console
The browser workspace is the complete surface — every feature appears here first, and some things (reading conversation transcripts, watching a live playground run, approving a rollout) only really work visually.
- Tour of the console — what each sidebar area does.
- Getting started — empty workspace to a working agent in about 15 minutes.
- Quick start — run an agent that already exists.
AI coding agent over MCP
MCP (Model Context Protocol) is a standard way for an AI assistant to use outside tools. MASAIC ships an MCP server, so you can point your coding agent at your workspace and then just ask for changes — no clicking, no command syntax to learn.
One command wires it up:
masaic login masaic mcp install claude-code
After that you can say things like "list the agents in this project and tell me which ones have no tests" and the assistant reads it straight from your workspace.
→ Control MASAIC from your coding agent
Not the same as connecting tools to an agent. This page is about an assistant controlling MASAIC. Giving your agents tools to call is the other direction — see MCP servers and tools.
The masaic CLI
The CLI is the choice when a change has to be repeatable and reviewable. You keep agent, prompt, model, and skill definitions as YAML files in your own repository, and apply them:
masaic validate -f ./masaic/agent.runtime.yaml # check it, no changes masaic apply -f ./masaic/agent.runtime.yaml # publish it
Because the definition is a file, a change goes through the same review your code does, and the same command runs in CI.
Which should I use?
| If you want to… | Use |
|---|---|
| See what your agent actually said to a customer | Web console |
| Build your first agent | Web console |
| Describe a change instead of making it by hand | Coding agent over MCP |
| Ask questions about your workspace ("which agents changed this week?") | Coding agent over MCP |
| Keep agent definitions under version control | CLI |
| Publish the same change to staging and production from a pipeline | CLI |
| Work across several projects without switching windows | CLI (--project) |
One warning worth reading once
The console, a coding agent, and the CLI all write to the same live workspace. A coding agent asked to "clean up the old agents" will do exactly that. Before you let an assistant make changes:
- point it at a non-production project or environment first (Environments);
- check Teams and access — the assistant acts with your permissions, not fewer;
- keep production promotion behind your normal release process (Safe rollouts).
← Sign in and your workspace · Control MASAIC from your coding agent →