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.
Workbench lives in a slim sidebar that snaps to the left or right edge of your screen. Hover it to expand it.
- Recent shows your recent Lore threads and local Workbench drafts.
- A working status shows which threads still have active work.
- Click a thread to open or return to its Workbench session.
- New thread opens a composer for starting work without leaving the sidebar.
Each active session opens in its own native window. In a session, you can mention Lore threads, use Workbench skills, and open artifacts produced by the work.
Keyboard shortcuts#
| Shortcut | Action |
|---|
⌘⌥T | Show or hide the Workbench sidebar |
The same action lives 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 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.
❦ Running Sessions ❦
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.
❦ Workbench Skills ❦
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.
❦ Attaching Files ❦
Attaching files#
Attach images and files to the next message in a Workbench session. Drop a file on
the composer, paste an image, or use the attachment picker. The desktop composer
also has a paperclip button. Attachments are shown as chips with their name and
size before you send the message.
Supported types are PNG, JPEG, WebP, GIF, PDF, plain text, Markdown, and CSV.
You can attach up to 4 images and 4 files to one message. Images share a 5 MB
per-message limit. Files share a 10 MB per-message limit, and each text file is
limited to 1 MB. PDFs are limited to 100 pages. SVG, Word, Excel, and other
unsupported formats are rejected.
Attachments are uploaded before the message is sent. The message stores only a
descriptor for each attachment; it does not store file bytes. The bytes are kept
in the private attachment storage used by Lore. Existing attachments remain
readable.
What the model receives#
- Claude and GPT can receive a PDF as a native document on the turn where it is
attached. If the document is too large for the model step, Lore uses its
extracted text instead.
- Grok receives extracted PDF text. Later turns use extracted text for every
provider, so you can ask follow-up questions without sending the PDF again.
- Text, Markdown, and CSV attachments are sent as wrapped text on every turn.
- GIF attachments use the first frame.
Lore extracts PDF text once when the file is uploaded. If extraction is not
available, the model receives a short placeholder naming the file. Figures and
other visual details in a PDF are available on the native-PDF turn only; attach
the PDF again when a later question needs its visuals.
Access and previews#
Each chip links to a preview or download URL. PDF previews open inline when the
browser supports them. Anyone who can read the thread can read its attachment,
including an anonymous viewer of a public thread. The same thread visibility
rules apply to attachment reads and no separate public attachment permission is
created.
❦ Session Sources ❦
Session sources are the working material the agent can draw 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.
What the agent saw#
Citation markers in answers link to the exact document, output, or Lore thread used for that part of the response. Select a citation to preview its source in the side pane. Restricted or unavailable sources remain marked without exposing their contents.
The agent can set a source aside when it stops being relevant. Setting a source aside changes the session context but does not change the original document or thread.
❦ Artifacts ❦
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 below the session toolbar 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.
❦ Forking Sessions ❦
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 ❦
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.
Four connectors are available today, all in preview:
- Notion: search and read pages the connected account can see.
- Granola: search meetings, read notes, and pull transcripts.
- Google Docs & Sheets: search and read the documents and spreadsheets you pick.
- Linear: list and filter issues, read one issue, and read its comment thread.
All of them read. None of them write: no connector can create a page, post a message, or file an issue.
Connect an account#
Open 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.
Pick the Google files Lore can read#
Notion, Granola, and Linear are scoped by account: the connector sees what the connected account sees. Google is scoped by file instead. Connecting the account grants nothing on its own, and you choose the files one at a time.
A connected Google row shows a Select files button that opens Google's own file picker. The files you pick there are the only ones Lore can ever read, and the button carries the count once you have picked some. The row's status line repeats the rule: "Lore can only read the files you select."
The picker offers both Google Docs and Google Sheets. Picking again adds to the list instead of replacing it, and picking the same file twice changes nothing. Reconnecting the same Google account keeps the list; connecting a different account clears it, and disconnecting drops it with the connection.
In a session, the Google tools stay inside that list. Search matches file titles only, across your selected files, so it never becomes a search of the rest of your Drive; it also tells the agent whether each result is a document or a spreadsheet. Fetch returns one selected document as Markdown. A request for a file you never picked is refused with the reason, not answered with an empty result.
Spreadsheets take two steps, because a spreadsheet's tab names cannot be known from the file alone. The agent first asks for the sheet and gets back its tab names and sizes, then asks again for one tab and gets that tab's cells. Reading a very tall tab returns the first rows and says plainly that it truncated, so the agent never treats a prefix as the whole sheet.
Reading from Linear#
Listing issues filters by any combination of assignee, status, team, project, label, and cycle, so "what is assigned to me" and "what is in this cycle" both work. A free-text query is available on top of those filters but is left off for a plain listing, because adding one narrows the result to text matches and a short list is easy to mistake for a complete answer. Fetching one issue returns its full description and metadata. The third tool reads an issue's comment thread, which is usually where a decision's reasoning lives when the description alone does not explain it.
The connector requests read access only, so a session can find and read your Linear work but cannot create, edit, or move anything.
Reading from Slack#
Search covers messages in public channels. Slack's search permission is broader than that on Slack's side, so Lore filters the results: anything from a private channel or a direct message is discarded before the agent sees it, even when the connected account could read it. Reading a channel or a thread is limited to public channels by the granted permissions themselves.
Message authors arrive as Slack ids rather than names, so there is a fourth tool that turns an id into a person. As with every other connector, nothing here writes: the agent cannot post a message or reply on your behalf.
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.