Build and share durable agent knowledge.

Workbench is Lore's agent for real work on your Mac. Each Workbench session is a chat window bound to a folder on your computer: you describe the work, and the agent reads and edits files, runs commands, browses the web, and produces documents, using your team's knowledge in Lore as it goes. Every session becomes a Lore thread automatically, so the work is shared, searchable, and forkable like everything else in your library.

Workbench is part of the Lore desktop app (macOS). You sign in with your Lore account; there are no API keys to configure and no model settings to manage. The agent itself runs on Lore's servers against your signed-in session, while your Mac executes the file, command, and browser actions.

The dock#

Workbench lives in a slim dock strip. Hover or click the collapsed handle to expand it. Each slot in the strip is one session:

• Click a slot to open or start its session. New sessions start in your home folder.
• Shift-click a slot (or the + button) to pick a different folder first.
• Alt-click a slot to rename it.
• Hover a slot for – (hide the session window) and × (put the slot away; the session's thread stays in Lore).

You can run up to 12 sessions side by side, each in its own folder and window.

The Navigator#

The orb at the strip's left edge opens the Navigator (⌥Space): a search panel over your Lore library, without leaving the desktop.

• Threads shows recent threads, or title matches as you type. Selecting one reopens it as a Workbench session, with its conversation restored.
• Skills lists your local and workspace skills; selecting one runs it.
• Artifacts finds files your sessions produced, yours or your workspace's, and opens them.

Arrow keys move through results, Enter opens, Tab switches groups, Escape closes.

Keyboard shortcuts#

The same actions live in the menu bar icon, along with Open Lore and Start at Login.

Signing in#

Workbench requires a signed-in Lore account. Signed out, sessions refuse prompts with "Sign in to Lore to use the Dock." and the Navigator, skills, and document editing are unavailable until you sign in again. Turns are metered against your team's Lore plan; if a turn stops with "Ran out of budget", that is the meter, not an error on your machine.

A session is a conversation with an agent that acts in its folder. Type what needs to be done and press Enter (Shift+Enter for a new line). While the agent works you'll see its progress ("Thinking…", "Responding…"), each action it takes as an activity chip, and a settled outcome when the turn ends. The composer stays typeable during a turn, so you can draft the next request while the current one runs; Stop cancels a turn you no longer want.

What the agent can do#

Inside the session's folder, the agent can:

• Read, write, edit, and delete files. Deletions are real deletions, so give sessions a folder you mean them to work in.
• Run shell commands, with a 60-second limit per command.
• Browse the web in a browser it opens on your Mac: navigating, reading pages, clicking, typing, and taking screenshots it can look at.
• Show its work: reports, briefs, and documents open in the artifact pane.

It also reaches your team's knowledge in Lore: searching threads, attaching them as sources, using skills, and reading connected tools.

The agent acts without confirmation prompts. You direct it by what you ask, which folder you give it, and the Stop button; the one hard brake is that a document you are actively editing is locked against agent writes until you're done.

Mention threads with @#

Type @ in the composer to search your Lore threads and mention one. Mentioned threads are attached to the session as sources before the turn runs, so the agent reads them as context. Deleting the @Title from your draft un-mentions it.

How turns end#

Every turn settles with an honest outcome line:

• Done: the work completed and its file changes were verified.
• Finished: completed, but not independently verified.
• Partially done: some of the work landed.
• Stopped: you cancelled it.
• Ran out of budget: the turn hit your team's usage meter.
• Something went wrong. Try again in a moment.
• Unconfirmed — needs review: the session ended in a state Lore could not confirm, with a reference you can quote when asking about it.

A quieter second line notes what happened to your files when that needs saying, and which set-aside sources were left out of the request.

Citations in answers#

When an answer draws on your sources, it carries small numbered markers. Click one to open the source it cites: a bound document, a Lore thread at the exact block, or an output file. A trailing i marker opens a summary of what was left out of context and why (sources set aside, earlier reads dropped, restricted material), so you can tell what the answer did not see.

Keeping the app current#

If a "Update Lore to restore file and command tools." notice appears above the composer, the desktop app has fallen behind the server and its local tools are paused. Use the Check for Updates button on the notice, then retry.

Your team's skills work inside Workbench sessions. Enabling a skill adds it to the agent's catalog; the agent applies a skill's instructions only when it activates that skill for the task at hand, so enabled skills stay inert until they're actually relevant and asked for.

Enable skills from the composer#

The + button in the composer opens a menu with Use skills: one checkbox per skill you can see, checked when it's enabled for your Workbench. Toggling here and toggling Use in Workbench on the Skills page write the same setting, so the two stay in step. Manage skills… in the same menu opens the Skills page.

Enabling pins the skill's current accepted version for you. If the owner publishes a new version later, your Workbench keeps using the pinned one until you enable the skill again.

Some shared skills are templates with inputs you have to fill in first. Enabling one of those before resolving its template is refused with the reason; resolve the template on the Skills page, then enable it.

While a skill is in use#

When enabled skills are active in a session, a caption above the composer names them, so you always know what standing instructions the agent is working under. Skill instructions can guide the agent, but they cannot grant it tools or permissions it doesn't already have.

See whether a skill earns its keep#

If you own a skill, its detail pane on the Skills page shows "Used in N recent Workbench turns": how many turns actually activated it recently. A skill nobody's Workbench ever activates is a candidate for a better description, or retirement.

Two kinds of material ride into a session: reference documents the agent can read throughout the session, and images attached to a single message.

Reference documents#

Choose Upload files… from the composer's + menu to add documents to the session. Text-native formats (Markdown, plain text, HTML, JSON, CSV, source code, and more) are copied in as-is; PDF and Word documents are converted to Markdown, with the original preserved alongside. Files can be up to 10 MB each.

Added documents appear as chips in the source rail, where the agent reads them and you can preview, pin, or set them aside. You can also add documents any time from the menu bar: Session ▸ Add Reference Document….

Images#

Show the agent something instead of describing it:

• Drag and drop image files anywhere on the session window.
• Paste a screenshot or copied image straight into the composer.

Staged images collect in a tray above the composer, each with a remove button, and are sent with your next message. A message can be images only; you don't have to add text. Up to 4 images ride one message (PNG, JPEG, or WebP), and oversized images, like full-resolution Retina screenshots, are scaled down automatically to fit the 5 MB per-message limit rather than refused.

The agent sees attached images on the turn you send them. Older messages keep a note naming the image, but the pixels themselves don't stay in context forever.

The source rail under a session's titlebar lists the working sources the agent is drawing on: reference documents you uploaded, Lore threads bound by @-mention or attached by the agent itself, and artifacts registered from earlier work. Threads are bound as point-in-time snapshots, so the agent reads what the thread said when it was attached.

Working with source chips#

• Click a chip to preview the source in the side pane.
• Pin a source to make it authoritative: pinned sources are always included in full on every step of a turn, never summarized away.
• Set aside a source to keep it bound but out of the agent's context; restore brings it back. Setting aside doesn't touch the file on disk.

Chip tooltips tell you each source's state ("Ready for Lore", "Still being added", and so on), and source controls go read-only while a turn runs. Up to six chips show inline; the rest fold behind a +N button.

If sources fail to attach or list, the rail says "Sources incomplete" with a Retry button, and a notice explains what went wrong.

What the agent saw#

Sources aren't just decorative: turn outcomes note which set-aside sources were omitted from the request, and citation markers in answers link back to the exact source. The agent can also set sources aside itself mid-turn when they stop being relevant; the rail always reflects the server's current truth.

When the agent produces something worth looking at, it opens in the artifact pane beside the chat: self-contained HTML pages, Markdown, plain text, and images all render in place. The pane resizes by dragging its edge, and Focus gives the document the whole window when you're reading rather than chatting (Collapse brings the chat back).

Publish an artifact#

Publish uploads the shown file to the session's Lore thread and copies a web link to your clipboard ("Link copied"). That's the fastest path from "the agent made this" to "there's a link for this".

Who can open the link is a separate question, answered by visibility. An artifact is always visible to everyone who can see its thread — sharing the thread always shares the artifact. On top of that, the artifact's author can publish it wider from the web app's Artifacts page: Share → Publish to workspace makes the artifact itself workspace-visible even when its thread is private. Publishing only ever widens the audience; making the artifact private again returns it to exactly the thread's audience.

The outputs list#

Outputs next to the source rail lists every file the session has produced. Each row offers:

• Save a copy… to write the file wherever you choose.
• Revise to seed the composer with a revision request for that file.
• Remove from outputs (and later restore) to curate the list without deleting anything.

Edit documents while the agent works#

Documents the agent writes in Lore's document format open as an editable page, not a static preview. You can edit inline, even mid-turn: a save chip tracks "Saving…" / "Saved", and while you hold an edit the agent's writes to that file are refused, so your changes can't be clobbered. If your copy and the agent's diverge, the editor keeps "your unsaved text, so you can put it back".

Work with claims#

In research briefs the agent produces, individual claims are selectable. Select one and Fan out expands it in place into its constituent evidence; select two and Compare inserts a side-by-side comparison, both preserving the original source ties. Clicking a claim also opens its evidence receipt (sources, inferences, uncertainties, limitations), and briefs with structured findings offer Publish to share a finding with your organization.

A session sometimes wants to go two directions at once: keep the main thread of work moving, and chase a side question with all the same context. Forking copies the session's history into a new session so both can proceed independently. Forked sessions are ordinary Lore threads, so the family is visible in your library too.

Ways to fork#

• The Fork button in the session titlebar forks into a new window beside the current one.
• Type /btw in the composer to fork in place: this window swaps to the fork, and the original keeps its state. Add a message (/btw check whether the API also needs this) and it's sent as the fork's first turn.

Forking waits for a quiet moment: a session mid-turn asks you to fork once the turn finishes, and a session with no messages yet has nothing to fork.

Finding your way around a family#

A forked session shows a ↩ parent breadcrumb; click it to swap back. The Forks control lists the whole family with an excerpt of each, and clicking a member swaps this window to it, so one window can walk the whole tree.

Connectors let the agent read from tools your team already uses, on demand, inside your own sessions. Nothing is indexed or copied into Lore ahead of time: when a turn needs something from a connected tool, the agent fetches it then and there.

Two connectors are available today, both in preview:

• Notion: search and read pages the connected account can see.
• Granola: search meetings, read notes, and pull transcripts.

Connect an account#

Open Connectors from the dock strip's connectors button, or visit the /connectors page in Lore. Each row shows the connection's workspace, when it was connected, and when a session last used it, with Connect, Reconnect, and Disconnect controls. Access grants expire eventually; a "Reconnect needed" badge and a reconnect prompt appear when that happens.

How sessions use connections#

Connections are personal: a session offers connector tools only when the thread's author (you, for your sessions) holds a live connection. They're also held back on public threads, since anything a connector fetches lands in the transcript, and a public transcript is visible to anyone with the link. Private and workspace-visible threads get the tools as normal.

When a connected tool can't be reached or needs re-authorization, the agent is told exactly that rather than seeing an empty result, so it will tell you to reconnect instead of confidently reporting that your document doesn't exist.