How d5s fits together

d5s separates ownership, reusable context, work behavior, and individual executions. The separation is deliberate: a scheduled job can reuse the same approved context as a chat without turning every earlier conversation into a new instruction. The same separation is what lets people and agents work on one body of work: a project holds the approved context once, so a colleague, an agent, and a scheduled automation draw on it without re-deriving it.

The hierarchy

1. An organization owns the broader member, group, billing, usage, audit, and residency boundary. It can contain multiple workspaces, and its Owners and Admins can compare usage across them without gaining access to workspace content. Inspecting the execution evidence behind one usage row rechecks access to the source conversation. Its region is selected when it is created; one user account can belong to organizations in several regions. Owners and Admins can change its display name while its URL slug and region remain stable.
2. A workspace is one day-to-day operating area. It contains projects and its own model, skill, connector, and API-key catalogs. Organization managers and workspace administrators can invite people into that exact workspace without opening the organization's other workspaces. If a team uses seats on joining, an organization Owner or Admin must authorize any new seat before the invitation is sent. Its display name can change while its URL slug remains stable.
3. A project owns the reusable context and sharing policy for a body of work.
4. A chat, agent, automation, or dashboard determines how work is initiated and presented.
5. A session is the durable conversation or execution record.
6. A run is one active attempt inside that record.

Every runnable activity has a project. Starting a chat, automation, or dashboard without selecting one creates a hidden, unpromoted project for that activity. Explicitly creating a project makes it visible in Projects, and Save as project can promote the hidden project behind a standalone chat. Staffing an agent creates a dedicated home project that is managed through the agent and intentionally excluded from Projects and project search.

How the work modes use sessions

• A chat keeps one interactive session with multiple turns.
• An agent owns one continuing session for its entire lifetime. Manual messages, manual wakes, and scheduled wakeups append to it.
• Each automation execution creates a new automation session, so run history stays independent.
• Each dashboard build or refresh creates a new dashboard session and can publish a new artifact version.

Context and capabilities

Context is what the agent can know: standing instructions, conversation history, project memory, and files. Capabilities are what it can do: follow a skill, call an activated connector, search the web, execute code, or create an artifact.

Workspace availability, project activation, and runtime approval are separate checks. For example, connecting GitHub makes a credential available in the workspace; activating it makes it available to one project; an Ask tool can still pause a run for a person to approve the exact action.

Word documents with tracked changes

Give an agent a Word file and ask for changes "as track changes". The agent returns a new copy with real Word revisions and comments under its own name, so the reviewer sees insertions, deletions, and reasons in the document preview and can accept or reject each one in Word. Revisions and comments that were already in the file stay untouched. The preview's Markup and Final views switch between the redline and the clean result.

Execution remains visible

A message or trigger creates a turn. d5s records admission, queueing, execution events, tool calls, usage, and a terminal result. A sandbox is provisioned when a run needs one; it is an execution environment, not the source of project memory.

This model lets you stop a run without deleting its conversation, branch a completed response into a new chat, inspect an automation's past executions, or restore an earlier dashboard version without losing the resource that produced it.