Publish workspace context for agents

You often need to give agents enough structure to generate correct queries, without copying large schemas into every prompt. With Workspace Context, you store documentation such as a data model once, and it is loaded automatically when queries run. You can list what context exists, push updates, compare it against the live catalog, and keep lightweight sandbox notes separate from shared workspace context.

How it works

Step 1 — See what already exists

What shared docs are stored for this workspace? If there’s a data model, show the whole thing.

Step 2 — Edit locally, push when the join graph changes

Pull the data model down so I can edit it on disk, then publish my edits back to the workspace.

Step 3 — Pair with live schema

Use hotdata tables list for column truth. Context explains relationships and business definitions (context:DATAMODEL). Context names follow the same rules as dataset identifiers.

I want to compare our written data model to what’s live in the catalog—show a slice of current tables and then show the DATAMODEL context so I can see definitions next to real columns.

Step 4 — Sandbox notes vs workspace context

Keep scratch work in sandbox markdown. Promote durable definitions into DATAMODEL (or another context stem) when they should guide the whole workspace. See Workspace context.

Jot a quick exploration note in my active sandbox, then publish my updated DATAMODEL from disk so scratch stays local and the team gets the stable definitions.

Who uses this

• Teams that deploy agents against a shared semantic description.
• Engineers who maintain join documentation alongside catalog discovery.
• Roles that maintain glossary or policy text next to technical mappings.