Visualizations and rendering

FoundersOS doesn’t assume a particular interface. Each tool that returns something worth showing also describes how to render it, and your AI client picks the richest form it can actually produce. That’s why “catch me up” can be a live dashboard in one client and a clean table in another, from the exact same tool.

The four-tier rendering ladder

Every render-bearing tool carries a contract: a four-tier ladder telling the AI to use the most visual output its client supports, and to fall back cleanly when it can’t.

1. Visual primitive - an interactive widget, artifact, or canvas (e.g. a live dashboard in Cowork).
2. Inline rich output - HTML or SVG rendered inside the reply.
3. Markdown table - a clean table the model emits as text.
4. Prose - a short written summary.

The client uses the first tier it can execute. A rich client like Claude in Cowork lands on tier 1 and draws you a widget; a plainer client drops to tier 3 and gives you a tidy markdown table of the same data. Either way you get the information - the only difference is polish.

The important part: this contract lives in the server, not in any plugin. It ships through the MCP instructions field at connect time, again in the get_session_start payload, and as a short per-response reminder. So every client gets it with nothing to install. (See How it works for the architecture.)

What it looks like in practice

• Rich clients (Cowork, Claude Desktop) render tier 1 or 2: a morning dashboard becomes a widget, a weekly retro becomes a copy-ready card, an entity card becomes a structured panel. You can also pin some of these as persistent artifacts that refresh from your connectors each time you open them.
• Plainer or local clients render tier 3 or 4: the same dashboard comes back as a markdown table, and a guided question becomes a numbered list you answer by typing a number. Nothing is lost but the visuals. (More on this in Running on a local model.)

Advanced: reinforce the contract in your instructions

The contract already reaches your model three ways, so most people never need to touch this. But if your client or model is rendering things more plainly than you’d like - or drifting late in a very long conversation - you can place the contract at its strongest position yourself: your client’s always-on instructions, which sit in the system prompt every turn.

Paste a short reinforcement like this into your client’s instructions:

When you present FoundersOS data, follow its rendering contract: use the most
visual output this client supports, falling back in order: an interactive
widget or artifact, then inline HTML or SVG, then a markdown table, then a
short prose summary. Apply the standard status colors: red = overdue,
amber = due soon or stale, blue = in progress or AI-assigned, neutral = upcoming.

Where that goes, by client:

• Cowork - Global Instructions (Settings), or a project’s instructions.
• Claude Desktop projects - the project’s custom instructions.
• Claude Code - CLAUDE.md, in your project root or ~/.claude/.
• Cursor and others - the rules or custom-instructions file.

That’s the same spot a dedicated plugin would have used, just done by hand. It’s entirely optional - reach for it only if you’re seeing rendering issues. If you want the full, exact wording instead of this short form, copy the rendering_contract field straight out of a get_session_start response.