Hubs and Library
Coordinate related work across agents and repositories with shared instructions, memory, and a versioned Library in Synara.
Hubs are available in Synara 1.0.2 Stable and Synara Beta.
Hubs are available in Synara 1.0.2 Stable and Synara Beta. A Hub combines one coordinator conversation, worker chats, shared context, and a Library of delivered files. It can cover several repositories or work without a repository for research, writing, and planning.
Create a Hub
Open Hubs → New hub, name it, and finish setup. Choose coordinator and thread models in General, add shared instructions in Memory, and link repositories in Environment. Setup alone does not launch a model; send the coordinator your first request when ready. In 1.0.3, Hubs is shown in the main rail by default. Existing saved settings reveal it once; hiding it again from Customize remains respected. The coordinator row opens its chat, the disclosure expands worker chats, and its hover controls offer pinning and Hub settings.
Tell the coordinator what outcome you want. It can answer directly, follow up with an existing worker, or start independent worker chats. Ask it to propose work before starting if that is your preference. New chats inherit the Hub's instructions and memory, while their provider and model can differ.
Follow delegated work
Task cards beneath your request show queued, starting, working, waiting, completed, failed, or cancelled work. Open a card to inspect its worker. Original request text and attachment references travel with the brief; keep source messages containing files until queued work starts.
New Hubs allow 3 parallel threads. In Hub settings → General → Parallel threads, choose 1–8. Excess tasks wait in a persistent queue. Repository workers default to isolated worktrees; general work and non-Git folders use a local workspace. Pausing or archiving the Hub prevents new queue starts.
The Hubs panel groups threads by whether they need you, are working, are ready for review, are idle, or are resolved. It also collects their pull requests, automations, and shared context. The server tracks delegated workers and reports completion, errors, and requests for input. It never approves a worker's pending request for you. If recovery needs your help, use Retry, Stop worker, or Open thread.
Shared instructions and memory
Use Hub settings → Memory to edit instructions, inspect MEMORY.md, and add or remove memory notes. Workers receive shared instructions and memory; coordinator planning and monitoring stay with the coordinator. Linked repositories determine where the coordinator can start repository work. It cannot steer unrelated chats just because they share a linked repository.
Keep deliverables in the Library
Open Library from the chat header. Upload files, preview documents, filter and search, or expand the panel for reading. Library changes are versioned in Git. History → Restore recovers an earlier version or deleted file.
For a remote backup, configure Environment → Library hosting → Git remote and Push on change. Configure working Git credentials first: background pushes are non-interactive. Inspect Pushed, Not pushed yet, or Push failed rather than assuming a local write reached the remote.
Pause, archive, and delete
Pause hub interrupts running work and stops new coordinator wakes and Hub automations; resume when ready. Restart coordinator keeps its transcript. Archive hides the Hub and its chats until restored.
Deleting a Hub removes its coordinator, context, and automations after name confirmation. Linked repositories and their chats remain. A custom Library folder is kept, while the default Library is moved to Trash when possible. Read the deletion notice for retained folders.
Hubs use the running app's data home; Stable and Beta keep separate Hubs and chats. The on-disk workspace parent retains its historical name, ~/Documents/Synara/Groups/. Beta data is not copied back to Stable; see Synara Beta for isolation and data-copy behavior.
Worker approvals in the coordinator chat
In 1.0.2-beta.1, pending worker approvals appear above the coordinator composer. Open the named worker or choose Approve once, Always allow this session when supported, Decline, or Cancel turn. Answering in either conversation clears the request in both. These are human controls; agents have no tool for approving a worker.
A task accepted into the Hub queue inherits the coordinator's access mode unless explicitly overridden, and retains that mode while queued. Changing an active chat's mode applies on its next turn. Hubs are available in Stable and Beta.
Source evidence: Synara v1.0.2 packages/shared/src/betaFeatures.ts, apps/server/src/projectAgent/Layers/ProjectAgentService.ts, apps/server/src/projectAgent/hubWorkService.ts, apps/web/src/components/chat/group/HubPendingApprovals.tsx.
Source evidence for 1.0.3 navigation: apps/web/src/appSettings.ts, apps/web/src/appRail.logic.ts and apps/web/src/components/SidebarGroupsSurface.tsx.
Access modes during check-ins
In 1.0.4, automatic coordinator check-ins use the access mode currently selected in the coordinator chat. A change during a running turn applies on its next turn. Ordinary scheduled automations keep their separately authorized saved mode.
New workers inherit the coordinator's mode unless explicitly configured otherwise. If the destination provider or model cannot use inherited Auto, the worker starts in Ask for approval; an explicit unsupported Auto request still fails validation. Claude Auto capability evidence is reused only for the same model and account. Devin approval-required workers use Code or Ask Everytime, depending on the advertised catalog.
The coordinator still cannot approve a worker's requests. Use the human controls described above.
Source evidence: Synara v1.0.4 (a62d7c733d19f5538ffc0d126d57437b3b578ff1) apps/server/src/automation/Layers/AutomationService.ts, apps/server/src/agentGateway/creationCoordinator.ts and apps/server/src/provider/Layers/DevinAdapter.ts.
Routing and follow-ups in 1.0.8
Delegated work retains the original human request and attachment references alongside the coordinator's brief. Keep source messages and their files until queued tasks start. A stable task key identifies each decision: retries and wakes reuse it instead of creating duplicate workers; a different plan under that key is refused.
Workers receive shared instructions and memory, while coordinator-only playbooks, monitoring rules and reports stay with the coordinator. Context labels identify human instructions, server state, Hub records and other agents' reports. Only the user grants authority for external actions. Ordinary follow-ups queue after the current turn; steer is for an immediate correction and can interrupt where native steering is unavailable. Non-Git workers can complete normally, and pausing/resuming a Hub no longer strands a settings save.