See the wholeworkflow.

Welcome to Glueprint. If you're working with coding agents, this is where you can bring the conversation, the code, and the review together. Let's walk through how it works, one part of the environment at a time.

We'll follow a small team building Signaldesk, a fictional product for exploring application logs. Taylor leads the release, Nico works on the interface, and Jamie looks after reliability. Alongside them, three assistants help coordinate, implement, and review the work.

There are four ideas to keep in mind. The host is the machine doing the work. A workspace holds the working files. A session is a coding conversation. And an assistant carries a role and useful context over time.

The team has a Thursday release to prepare. They need better log search, a helpful empty state, and a retention check. We'll follow those changes through the product, so you can see how the pieces fit together.

Let's start with a place for the work. A project identifies your repository. Inside it, you create a workspace for the change you're making. Before starting a session, check the host, the repository, and the branch.

Here, search and the empty-state fix need to move independently. Giving each change its own worktree keeps their working files separate. They still share repository history, so the branches come back together through review and integration.

Within a workspace, you can arrange the tools around the task. Put the conversation in one pane and a terminal in another. When you need more room for a file or a result, adjust the split.

As you switch between workspaces, the sessions and project commands stay connected to the right work. The sidebar keeps those branches in view. For a larger project, the command palette and workspace shortcuts make moving around quicker.

Now we're ready to start a session. Choose an installed coding agent, such as Claude Code, Codex, or Gemini, and confirm the workspace. The model and reasoning options you see depend on the agent you've selected.

Then describe a result someone can check. For search, we want to match service names and messages, preserve the order of events, and cover empty queries. That gives the agent a clear target and gives the reviewer something concrete to verify.

Once the agent starts, the transcript brings its messages, tool calls, edits, and command output into one timeline. You can open a tool call for detail or follow an edit into the file it changed.

The conversation can keep going as the work develops. Add an image, point to a file, or explain what still needs attention. Specific feedback gives the next turn a useful direction while keeping the original task in context.

Some decisions still need your input. Here, retention reaches a policy question: should audit events stay longer than ordinary logs? Glueprint keeps the question and its answers visible. You can choose an option or write your own response.

An approval request serves a different purpose. It asks whether an action may run. Review the tool and its arguments, and choose a permission mode that fits the work. The exact controls depend on the coding agent.

While retention waits, the search feature and empty-state fix can keep moving. Each session has its own process and pending decisions. You can see which stream needs attention without putting the entire project on hold.

And you can intervene when the direction needs to change. Interrupt the current turn, give a follow-up, or stop the session. The transcript and session details help you understand what's happened before deciding how to continue.

When an agent says a change is ready, open the file behind that claim. Glueprint keeps editing close to the conversation, so you can move from a summary to the implementation without losing the surrounding task context.

In the diff, read additions and removals together. For Signaldesk, we're checking how search filters events and what happens when nothing matches. Inline and side-by-side views help you inspect the change at the level of detail you need.

The editor also supports language-aware assistance through language servers. Completion and diagnostics depend on the tools installed for the project and host. You can inspect the relevant editor preferences and language configuration in settings.

Documentation belongs in this same loop. Open the release notes beside the code and check that the explanation matches the behavior. Markdown supports both rich and source views, so writing and reviewing the documentation stays part of the development work.

Sometimes the quickest way to understand a result is to run the command yourself. A terminal in Glueprint is a real shell on the selected host, in the selected workspace. Keep it beside the session while you investigate.

For commands you'll use repeatedly, the project runner brings supported scripts and configured tasks into view. Tests finish with a result; development servers keep running. Each workspace keeps the commands and runs that belong to its files.

Here, the log tests have completed. Read the output and the exit state alongside the session summary. In your own project, this is where you confirm that the actual checks cover the behavior you're about to accept.

For a deeper investigation, the debugger lets you pause inside the program. This example stops in a search test, with the current query, stack, and local variables visible. You'll need the appropriate runtime adapter and launch configuration for your project.

Next, let's look at the experience we're changing. The browser preview puts Signaldesk's event list beside the development work. You can try a query, clear it, and see whether the interface makes the result easy to understand.

When something needs refinement, point directly to it. An element annotation carries the selected interface detail and your comment into the conversation. Here, the feedback asks for a clearer search label, giving the agent a precise next step.

Port forwarding helps when the service runs on another Glueprint host. Select the right host and service, then reach it from your other signed-in surfaces. The service and its source files continue to live on the machine running them.

Mobile development can use a virtual device inside the workspace, too. With the platform tools installed, you can select a device, interact with it, and capture feedback. Android needs its emulator tooling; the iPhone simulator needs a Mac with Xcode.

Once the behavior looks right, it's time to review what will actually be delivered. Open Changes, inspect the working tree, and stage the intended files. Search and the empty-state fix can each have a clear, focused commit.

When branches need to come together, check the destination before merging. The preflight helps you inspect the working tree and relevant session state. In this example, the reviewed empty-state change is integrated into the search feature.

A pull request gives the next reviewer the reason for the change and the evidence behind it. Describe the matching behavior, the empty state, and the tests. Check the base branch and draft status before creating it.

Then follow the checks and make the release decision with the full picture in view. Passing tests, the diff, and the behavior all matter. Glueprint connects the development work; your project's delivery system handles the deployment itself.

Sessions show how work happens. Boards help everyone see what still needs to happen. Signaldesk's board separates search, the empty-state fix, retention tests, and release review, with ownership and progress visible across the team.

Open a task to understand its intended outcome before starting. The details and discussion explain the problem, while links to sessions and worktrees connect the implementation back to the request that prompted it.

Different views help you focus on different questions. You might want to see everything in progress, just your assignments, or the work ready for review. You're changing how you look at the work, while keeping the underlying tasks connected.

If your team uses GitHub Issues, you can bring those into the workflow as well. Starting from an issue opens a prepared session composer. Review the prompt and workspace before sending it, with the original issue still connected to its provider.

A release also needs a place for the team to talk. Channels bring the relevant people and assistants into a shared conversation. Here, Signaldesk keeps release context together, while direct messages support more focused exchanges.

Use a thread when a detail needs discussion. The retention question and its replies stay together, so another teammate can catch up on the reasoning. That makes the decision easier to find when review comes around.

You can ask an assistant to join in with a mention. Its wake policy determines when it responds, and its reply returns to the channel, thread, or direct message that prompted the work. The conversation keeps its context.

This is also where feedback and evidence can meet. Builder proposes the implementation, Check reviews it independently, and the team can discuss the result. Taylor's final decision stays connected to both the change and the review.

A persistent assistant is useful when a responsibility continues beyond one session. It has a name, instructions, memory, and a configured coding agent. Here, Compass keeps track of release health and helps coordinate the next useful step.

Start with a specific role. Explain what the assistant should watch, what good work looks like, and what it should report. A focused responsibility makes its output easier to evaluate and its behavior easier to guide.

Then make the boundaries clear. In this example, the constitution keeps changes focused on release checks, asks Check to review Builder's work, and leaves merge and deployment decisions with Taylor. Tool permissions and runtime approvals add further controls.

You can open the assistant to inspect both its configuration and the sessions it launches. That gives you a way to understand the work behind a report. The assistant also belongs to a host, where that work runs.

As an assistant works, some lessons should last. Compass has learned that a cached build must still run the smoke checks. Saving that as project memory gives future sessions a useful rule to carry forward.

Reference material provides another kind of context. You can supply a release runbook or other authoritative document for the assistant to consult. Keeping those references focused and current gives recurring work a reliable starting point.

The journal records what happened on a particular day. It captures the investigation and outcome, while long-term memory holds the lesson that should influence future work. History gives you a way to inspect how that context has changed.

Reports and drafts belong on the workbench. Here, the release-readiness report collects evidence from this run. Keeping the report separate from the durable rule makes it easier to find both what happened today and what should happen next time.

When a useful task should repeat, make it a routine. This schedules agent work over time, such as checking release evidence each weekday. Give it a clear purpose and an output you'll know how to review.

Choose the working directory and permission mode deliberately. If the routine makes changes, a fresh worktree can help keep each run separate where supported. The host also needs to be available when the scheduled work is due.

After a run, inspect its result. The history shows what happened, and the associated session provides the detail behind the summary. A recurring task becomes useful when you can tell whether it completed and what it found.

On the next check, Compass can apply the saved cache lesson again. The responsibility continues, and Taylor still owns the release decision. For work that needs a steady home, a server running the Glueprint daemon can provide the host.

There are several ways to divide up a larger job. Within a session, an inline subagent can take a bounded piece of work. Its activity appears with the parent conversation, and both run on the same host.

For a broader objective, orchestration represents the work as tasks with dependencies. Independent tasks can proceed together, while dependent work waits for its prerequisites. This private execution plan is separate from the shared boards your team uses to track work.

A decision gate marks a point where direction is needed. It blocks the relevant task until the decision is resolved. After that, the remaining prerequisites still determine whether the next task is ready to run.

Workers report back to the coordinator, including when work spans hosts. If a task needs another attempt, its earlier result remains part of the record. That gives the coordinator evidence to use when choosing the next step.

The host selector keeps the location of the work explicit. You can follow sessions across macOS, Windows, and Linux. Here, the Mac handles search while a Linux server checks retention, and both streams stay visible from the same environment.

When you're away from your desk, you can answer from your phone. Taylor chooses to keep audit events longer, and the agent continues on its original host. The decision reaches the work without moving the process or its files.

The web portal provides another way to follow and act on supported workflows. Desktop, web, and mobile are different views into the same environment. What's available depends on the host's connection, your permissions, and the capabilities of that surface.

For a server, the command-line daemon gives work a home without a desktop window. You can inspect status, find sessions, and run the host. Installing it as a service lets the operating system manage its lifecycle.

Finally, connect the tools that fit your workflow. Agent extensions shape what a coding agent can use, while app plugins add product workflows such as GitHub Issues. Check the host, connection, and permissions as you configure them.

Then make the environment comfortable to use. Explore the command palette, adjust keyboard bindings, and choose appearance and notification preferences that suit you. Small changes here can make everyday navigation feel much more familiar.

The best place to begin is one real task in a repository you know. Take it from a clear request through implementation and review. Add parallel work, shared channels, a persistent assistant, or a routine as they become useful to your team.

That's the full tour. You can use the chapter list to revisit any capability, open the notes for more detail, or try the practice prompt for that section. Start with a useful change, and keep the work in context.