Skip to main content
Contents
5 min read

AI Companion

Companion Workspace

Understand the intended dedicated page for durable conversations, explicit context, proposal review, permissions, usage, and immutable action receipts.

App path

  • Planned dedicated AI Companion workspace
  • Global navigation -> AI Companion

What the Companion Workspace is for

Intended v1 surface: The dedicated Companion Workspace is planned but is not available in the current workstation baseline. Until its release gate passes, use the global Companion Chat.

The Companion Workspace is the future full-page home for longer AI-assisted work. It keeps durable conversations, selected context, authoring proposals, Result explanations, usage, permissions, and action receipts together without turning the global chatbot into a crowded control panel.

Use the global Chat for a quick question while working elsewhere. Use the dedicated Workspace when you need to return to a conversation, compare several proposals, inspect a detailed diff, or audit what the Companion was allowed to do.

Manage conversations

The intended Workspace provides a local conversation list and an active conversation area. You will be able to:

  • create and name a conversation;
  • reopen it after navigating away or restarting the workstation;
  • continue with the same explicit provider, model, and context rules;
  • search or filter local history;
  • rename or archive a conversation;
  • export a conversation with its context and action references; and
  • delete a conversation and verify its local removal.

Conversation history remains separate from provider retention. Deleting a local conversation does not delete data a hosted provider retained under its own policy.

Build an explicit working context

The Workspace will let you add exact, bounded workstation objects to a conversation: Dataset and Prepared versions, Signals, Strategies, Portfolios, Studies, Results, Jobs, and Notebooks. Every attachment keeps its identity and version, and the disclosure shows the fields or artifact excerpts sent to the model.

Changing the selected object does not silently replace earlier context. The Workspace should identify stale or superseded versions and require you to refresh or remove them. Credentials, unrestricted datasets, full account records, raw plugin repositories, and arbitrary local files remain excluded.

Develop and author ideas

Use a Workspace conversation to move from an idea to a reviewed proposal:

  1. describe the behavior, constraint, or problem;
  2. compare alternative Signal or Strategy approaches;
  3. choose one direction and state the required data and execution level;
  4. create a typed Signal, Strategy, Portfolio, Study, or Notebook proposal;
  5. inspect its parameters, dependencies, assumptions, and validation findings;
  6. revise or reject it; and
  7. send an accepted proposal to the owning feature as a new draft or version.

The conversation is not the saved object. Signals, Strategies, Portfolios, Studies, and Notebooks remain authoritative only in their own libraries and editors.

Review Results and Strategy improvements

For a Result review, attach the exact Strategy version, Study or Run Output, and the bounded retained fields needed for the question. The Workspace can then organize explanations, unresolved questions, and proposed follow-up work in one place.

When recommending Strategy improvements, it should show:

  • the exact source version and Results reviewed;
  • the observed weakness or limitation;
  • the proposed change and before/after diff;
  • the expected trade-off, not a promised benefit;
  • the data and fidelity needed to test it;
  • validation findings and unsupported claims; and
  • the new Study required to compare the proposal.

Keep separate proposals separate. This makes it possible to test whether a filter, exit, sizing rule, or risk change helped, rather than attributing an outcome to an opaque bundle of edits.

Review permissions before an action

The intended Workspace displays the Companion's current permission profile. Read-and-propose is the default. A limited autonomy grant must name the exact operations, objects, environment, budget or count limit, expiry, and revocation control. The model cannot broaden or renew its own grant.

Before any effect, review the typed proposal and owner validation. Destructive, credential, external-account, and Live trading operations are outside the v1 Companion tool set. Manual Live controls retain their own readiness, confirmation, and receipt contracts.

Inspect proposals, tool use, and receipts

The Workspace should present a readable trail rather than hiding work behind a chat response:

  • context disclosure and provider/model identity;
  • each bounded tool request and result;
  • validation findings and declined operations;
  • proposal version and before/after diff;
  • approval or limited autonomy grant;
  • cancellation, failure, and partial-effect state; and
  • immutable action receipt linked to the owning object or job.

A Trust Record proves that an AI request was processed under a particular disclosure. It does not prove the answer is correct. An action receipt records an attempted or completed effect; it does not prove that a Strategy will perform well.

Follow usage and limits

The dedicated page will show request usage, configured budgets, active calls, and provider-reported estimates where available. The provider's billing system remains the final cost authority. Arizmic must not silently switch providers, models, or data destinations when a limit is reached.

Use Stop to end generation that is still streaming. For an action already accepted by an owning workflow, stopping the text response does not prove the effect was canceled. Reconcile the action receipt or owning job before retrying.

Privacy and deletion

Conversation content, selected-object references, proposals, and local history remain inspectable and deletable on the workstation. Action receipts may have a longer retention requirement because they record a product change; the delete screen must explain that distinction before removal.

Hosted prompts follow the selected provider's retention and processing terms. Local models remain local only when the configured endpoint and model server do not forward requests. Neither route gives the Companion access to provider keys, broker credentials, or excluded fields.

Release gate

The dedicated Workspace must remain labeled planned until the application can demonstrate:

  • durable local conversation create, reopen, export, and delete behavior;
  • exact selected-object context with disclosure and redaction;
  • provider capability snapshots and no silent failover;
  • streaming, Stop, timeout, and unknown-outcome recovery;
  • schema-constrained proposals that use owning validators;
  • scoped approvals or autonomy with current-state revalidation;
  • immutable receipts for every effect;
  • usage and budget presentation;
  • keyboard, narrow-screen, and assistive-technology access; and
  • enforced exclusion of unrestricted files, network calls, credentials, and Live commands.

Until those gates pass, this page describes the intended v1 workflow rather than an available route.

Next

Configure a provider in Model Connections and use Companion Chat for the current global entry point.