Workspace Context

• Workspace context is versioned Markdown attached to a workspace and prepended to every agent session that runs in that workspace.
• It has its own draft-and-publish lifecycle. You edit a draft, review it, and publish it. Published context is what agents see on their next session.
• Workspace context is not the same thing as an LLM's context window. It is a piece of content Guild manages; the context window is a runtime limit on the model.
• Workspace context is edited and published through the CLI (guild workspace context edit, guild workspace context publish) or the app.

Workspace context is a piece of Markdown content stored on a workspace and automatically prepended to the message stream of every agent session that runs there. It is Guild's answer to a very common question: how do you give every agent in a workspace the same shared understanding of your systems, conventions, and vocabulary without editing each agent's prompt one by one?

Instead of teaching every agent your team's terminology, your service ownership map, or your escalation policy inside its own instructions, you write it once as workspace context. Every session in that workspace starts with that content in front of the LLM.

Versioned content with a draft/publish lifecycle

Workspace context is versioned. You edit a draft (guild workspace context edit <workspace-id>), which opens the current draft in your $EDITOR. Publishing a draft (guild workspace context publish <workspace-id> <context-id>) turns it into the version that new sessions will see.

Prepended to every agent session

When an agent session starts in a workspace, Guild automatically prepends the published workspace context to the session's message history. From the LLM's point of view, the workspace context is just the first thing it reads. From your point of view, it is content Guild ships to every session without you having to remember to include it.

Distinct from the LLM's context window

"Context window" in LLM parlance is a hard token limit, how much text the model can process at once. "Workspace context" is Guild's name for a piece of content that gets injected into that window on every session. They share the word "context" but they are different concepts. Workspace context is content; the context window is capacity.

Managed like any other versioned artifact

Because it is versioned, workspace context can be listed (guild workspace context list), fetched by version (guild workspace context get), edited from a specific prior version (--from <context-id>), and published or rolled back as a normal operation. It behaves like source-controlled content, not a form field.

Shared knowledge belongs at the workspace, not per agent

Every organization has terminology, conventions, and rules that every agent should know. Writing them into each agent's system prompt is redundant, error-prone, and hard to change consistently. Workspace context puts that knowledge in one place, versioned, and applies it uniformly.

Agents need environment awareness

An agent behaves differently depending on where it is running. An agent running in staging should know it is in staging. An agent running in a customer-support workspace should know which product the team supports. Workspace context is where that environmental signal lives.

Governance benefits from a shared header

When workspace context is versioned and reviewed, changes to it are auditable. That matters for regulated environments where "what did the agent know at the time of the incident" is a real question with a real answer.

Edit and publish context for a workspace

guild workspace context edit <workspace-id>            # Edit in $EDITOR, creates draftguild workspace context list <workspace-id>            # List context versionsguild workspace context get <workspace-id> <context-id>   # Get a specific versionguild workspace context publish <workspace-id> <context-id>  # Publish a draft

Edit from a previous version

guild workspace context edit <workspace-id> --from <context-id>

Starts your draft from a specific prior version, useful for reverting or forking a known-good context.

Common patterns for what to put in workspace context

• Product and service ownership maps ("The orders service is owned by the growth team")
• Team conventions and vocabulary
• Environment signals ("This is the staging workspace. Do not send production alerts.")
• Escalation rules and approval requirements

Workspace context is prepended to every session

It costs tokens on every session in the workspace. Keep it disciplined. Add what every agent genuinely needs to share. Push agent-specific instructions into the agent itself, not into workspace context.

Draft vs. published behavior

Only published versions apply to new sessions. Drafts exist so you can review before shipping. When you publish, the change takes effect on the next session that starts in that workspace, not on active sessions.

Not the same as the LLM's context window

The two often get conflated. Workspace context is content Guild manages. The context window is a runtime capacity limit imposed by the underlying LLM. Confusing them leads to bad design decisions ("I'll just put more in workspace context" is not the answer to a context-window overflow).

Versioning is your rollback path

If a published context change breaks how agents behave, roll back by publishing an earlier version with guild workspace context publish <workspace-id> <earlier-context-id>. Treat context changes the same way you treat production config changes.

Guild is a control plane for AI agents, a place to build, deploy, and govern the agents your teams run in production. Workspace context is how the same set of agents behaves consistently across an entire environment without you having to edit each one.

• The CLI reference for workspace context lists every command.
• The workspace glossary entry is the parent concept if you're new to how Guild organizes agents.
• Explore the Guild CLI and the rest of the platform at guild.ai.