Agents

Use configured assisted automation with explicit tools, limits, and session state.

The Agents surface is an experimental, bounded research automation workflow. An agent has a definition, a model/backend preference, allowed tools, runtime limits, optional memory, and a session trace. Treat it as assisted automation whose model-generated hypotheses and conclusions need human review, not as unsupervised scientific judgment.

What Is Implemented

  • agent definitions with templates such as literature reviewer, citation analyst, data extractor, writing assistant, cluster explorer, and discovery researcher; template names do not establish scientific capability
  • one or more agent sessions with their own state, chat, tool calls, and run history
  • BYOK or local model selection through the same AI backend configuration used by the desktop assistant; managed cloud AI is not active during Public Alpha
  • allowed-tool lists, runtime limits, token limits, and autonomous iteration limits
  • action candidate evaluation, action decision ledger entries, and action outcome records for tool-heavy autonomous runs
  • proof obligation and portfolio-review tools used by the scientific discovery workflow
  • exported discovery reports and run metadata under the local application data area

Safety Boundary

Experimental autonomous runs are bounded. The orchestrator records candidate evaluation before heavy actions, stores a decision entry, runs one bounded action, and records the outcome. Policy/tool gates and approval-oriented UI paths are still part of the control story, so do not treat an agent run as a final authority.

Deterministic verification and model-generated reasoning are different things:

  • deterministic tooling can record ledgers, proof obligations, formalization attempts, and verifier status
  • model output can propose hypotheses, summaries, branches, and next steps
  • only verified artifacts should be presented as verification evidence

Where To Click

| Entry point | What opens | | --- | --- | | Agents card on Help/Landing | The agent orchestrator tab | | Agents tab in the main tab bar | The same orchestrator, without going through Help/Landing | | Agent-specific launch action inside the orchestrator | A dedicated chat/session surface for that agent |

Workflow

  1. Open the Agents tab from Help/Landing or the tab bar.
  2. Choose or configure an agent definition with the tools and backend it is allowed to use.
  3. Start a session and watch the trace, tool calls, candidate decisions, and outcomes.
  4. Stop, refine, or restart the run when the goal changes.
  5. Review exported reports and source links before using the result in writing or decisions.

Local vs Cloud

Agents reuse the backend selected in Settings -> AI. A run can stay local when it uses local models and local data, but provider search, account-linked services, and network MCP transports require network access. Managed cloud AI is not active during Public Alpha.

The same rule applies when an external MCP client starts an agent workflow. MCP can call the agent and research tools, while the model route still comes from the configured desktop AI backend:

  • managed cloud AI is not active during Public Alpha; future availability and timing are not published
  • BYOK uses the user's configured provider key
  • Ollama or the native worker keeps generation local where the workflow supports it

For one focused discovery/evaluation path, read Agent Research. For external automation, read MCP & Headless.