Open app →
Documentation

AI & the assistant

Connect your own model key, turn AI on or off, talk to your workspace with the Ask and Build assistant, search the web, use the AI writing helpers, and keep every call accountable in the run log and credit usage.

What this page covers

Elliptic is an agent-native work platform, Jira for your agents and your team, and AI runs through all of it. This page is about the AI you touch directly: the model key your org connects, the on/off switch that gates it, the in-product assistant you chat with, the web search and writing helpers it gives you, and the accountability layer (a run log and per-seat credits) that keeps every call honest. The same key and the same surfaces back the agents that operate Elliptic over the company-brain MCP, so everything here is one system, not a bolted-on chatbot.

The one rule, restated
Every AI feature in Elliptic runs on your own model key. There is no hidden Elliptic model and no shared, pooled inference bill. You connect a key once, and summaries, answers, the assistant, writing helpers, and agents all run on it, on your account, at your cost, with full token visibility. This is what BYOK (bring your own key) means everywhere in the product.

BYOK: connect your own model key

Before any AI feature works, an admin connects at least one provider key under Settings → AI. You paste the key, give it a name, and it becomes available to every AI surface in the org. Adding and managing keys is an admin (or owner) action.

Which providers you can connect

Elliptic speaks to several provider families, so you are not locked into one vendor or one hosting model:

ProviderHow it runs
OpenAIHosted OpenAI chat completions on your sk-… key.
AnthropicHosted Anthropic Messages API on your key.
OllamaOpenAI-compatible. Point base_url at your Ollama endpoint to run open models locally or on your own box, no hosted vendor involved.
Custom (OpenAI-compatible)Any endpoint that speaks the OpenAI chat-completions shape. Set base_url to your gateway or self-hosted server.
AWS BedrockStored only. You can save Bedrock config (a region and a chat model), but execution (AWS SigV4 signing) is not implemented yet, so a Bedrock call returns "AWS Bedrock execution is not yet supported."

Ollama and custom providers route through the OpenAI-compatible path using the base_url you configure, which is how Elliptic supports local and self-hosted models for air-gapped or privacy-strict deployments.

Why BYOK matters

  • Your data, your account. Each call goes straight from Elliptic to your provider on your key. The model relationship is yours, never resold through a middleman.
  • Your cost, fully visible. You pay your provider directly at their rates. Elliptic records the tokens of every call, so you see real usage, not a bundled markup.
  • Your choice of model. Because the key is yours, you pick the exact model id, a fast cheap one for triage, a stronger one for summaries. Each key can pin its own default chat model.
  • Your hosting model. Hosted OpenAI or Anthropic, a local Ollama box, or a custom OpenAI-compatible gateway, all behind the same BYOK contract.

Add a provider key

  1. Open AI settings
    Go to Settings → AI. The Provider keys card is where keys live. Adding and managing them is admin-only.
  2. Pick the provider
    Choose OpenAI, Anthropic, Ollama, Custom, or Bedrock from the provider dropdown. For Ollama and Custom you also set an endpoint URL (the base_url) and an optional chat model; for Bedrock you set an AWS region and a chat model.
  3. Name the key
    Give it a recognizable name like "OpenAI – production" or "Anthropic – team". Names must be unique within your org, so you cannot accidentally store two keys under the same label.
  4. Paste the secret
    Paste the full API key. It is treated as a write-only secret, masked as a password field on entry and never echoed back.
  5. Save
    Click Add key. Elliptic encrypts the secret, keeps only its last four characters for display, and logs the addition to your activity feed.

Named keys, defaults, and how a key gets chosen

  • Named keys. A key has a friendly name, unique per org. You can hold several keys across providers and several within one provider, for example a production and a staging OpenAI key.
  • Default per provider. Flip the Default switch on a key in the list to make it the one AI reaches for. There is one default per provider, and turning on a new default automatically clears the previous default for that same provider.
  • Resolution order. When a feature needs a key it resolves in this order: an explicitly named key id, then the default for the requested provider, then the org's most recent default key overall. If nothing matches, you get a clear error (below).
  • Rename and re-default any time. You can rename a key or change which one is default without downtime. The secret itself is immutable: to rotate a key, add the new one and delete the old.

Optional upstream validation

When a key is stored, Elliptic can validate it against the provider with a free models-list call. A 401 Unauthorized means the provider rejected the key and the save is refused with "Provider rejected this API key." A rate-limited response (429) still counts as valid, so a busy account is never wrongly turned away. Validation only applies to the hosted OpenAI and Anthropic endpoints. For Ollama, custom, and Bedrock keys it is skipped and the key is accepted on trust, since there is no universal way to check them.

Encryption and the last-4 display

A key is encrypted the moment it is saved, using AES-256-GCM authenticated encryption with the organization id bound in as additional authenticated data, so a key encrypted for one org cannot be decrypted in the context of another. The raw secret is write-only: after you save it, only the last four characters are ever shown again, and the plaintext cannot be read back out of Elliptic, not even by you. When a feature actually needs to call the provider, the key is decrypted just in time for that single call and never lingers in a readable form.

No key, no AI
If your org has not connected any usable provider key, AI features return a clear error: "No AI provider key configured for this organization." Connect a key under Settings → AI first and every downstream surface lights up.

Turning AI on or off

Independently of keys, an org has a single workspace AI switch, on the same Settings → AI page. It is on by default. An admin can flip it off to disable all AI at once, for a compliance freeze, an incident, or a period when you simply do not want any model calls leaving the workspace.

When AI is switched off, every AI surface (the assistant, web search, writing helpers, estimates, charts, meeting summaries) refuses with the same clear error: "AI is disabled for this workspace." Turn the switch back on and everything resumes, using whatever keys you already have stored. The switch gates execution only. It does not delete your keys, conversations, or run history.

The in-product assistant

The assistant is a chat surface that talks to your workspace. Open it and you get a list of conversations on the left and the active thread on the right. Every conversation has a mode that decides whether it can change anything: Ask is read-only, Build can take action. You start a new chat by clicking Ask or Build, and you can switch a conversation's mode later.

Ask: read-only questions about your work

An Ask conversation is a concise, practical helper for questions about your projects, work items, cycles, and pages. It is strictly read-only: it cannot change any data, and if you ask it to make a change it will tell you to switch the conversation to Build mode. Use it for "what's the status of WEB-42", "summarize the open work in the Platform project", or "what did we decide about pricing".

Build: conversations that can act

A Build conversation helps you take actions on the workspace. In chat it describes the concrete change it would make, the entity, the fields, and the values, and it is told to respect your role and permissions. The actual mutation happens through the propose, confirm flow described below, never silently from a chat reply.

Living with your conversations

Conversations are persistent and personal to you. Each one supports the housekeeping you expect:

  • Rename. Double-click a conversation in the sidebar to give it a meaningful title.
  • Auto-title. A fresh conversation starts as "New chat" and is automatically titled from your first message (trimmed to a short label), so your sidebar stays readable without any effort.
  • Pin. Pin the conversations you return to. Pinned chats sort to the top of the list.
  • Search. The search box filters your conversations by title, so a long history stays navigable.
  • Per-message feedback. Every assistant reply has thumbs-up and thumbs-down. Your rating is stored on that message (and clicking the active thumb again clears it), giving you a record of which answers landed.
  • Delete. Remove a conversation you no longer need. It and its messages are gone.

@-mentioning projects and work items

To ground a question in something specific, @-mention it. The mention picker lets you reference a project or drill into a project to reference an individual work item (task). Mentioned items are resolved into a context block the assistant sees, the project's name and key, or the work item's title, status, and a slice of its description, so its answer is anchored to the exact thing you pointed at rather than guessing from the name.

Attaching files

You can attach files to a message. Text files (plain text, JSON, and XML) are read and inlined into the assistant's context, truncated if very long, so it can actually reason over their contents. Binaries and images are referenced by filename so the assistant knows they exist and can talk about them, with full image vision pass-through noted as a follow-up. Attachments stay bound to the message you sent them with.

Build mode: propose, confirm, execute

Build mode never mutates your workspace from a chat reply alone. It follows a deliberate two-step path so you always see the exact change before it happens, and so the change runs with your own permissions.

  1. Propose
    In a Build conversation, type what you want and click Propose. The model turns your request into one structured action and returns a plain-language summary, for example "Create work item “Fix the signup race condition” in WEB (priority: high)". Nothing has changed yet.
  2. Confirm
    Review the proposed action. If it is right, click Confirm & run. If not, discard it and rephrase.
  3. Execute as you
    On confirm, Elliptic executes the action through the normal RBAC-checked service layer, as you. It is exactly as if you had created the item by hand: your role and permissions apply, and the new work item gets its real KEY-number identifier.

Today the supported Build action is creating a work item. The model picks the target project from the projects you actually have, snaps the priority to a valid level (none, low, medium, high, or urgent), and Elliptic re-validates the project on execution, so a proposal can never land work in a project that does not exist or that you cannot touch. If you have no projects yet, Build mode tells you to create one first.

Auto-run with batch review

A Build conversation has an optional Auto-run toggle. With it on, the Run button proposes and executes an action in a single step, skipping the separate confirm click for speed. Each auto-run action is still recorded and added to an on-screen batch review list, showing the identifier and summary of everything that was created, so a faster loop never means a blind one. Auto-run is only available in Build mode.

Confirm by default, auto-run when you trust it
Leave auto-run off while you are getting a feel for how the assistant interprets your requests, so you confirm each action. Turn it on for a focused session of bulk creation ("add these eight tasks to OPS") where reviewing the batch afterward is enough.

Web search from the assistant

The assistant can answer from the open web, not just your workspace. Type a question and click the globe to run a web search. Elliptic fetches results, then has your org's model synthesize a concise answer grounded only in those results, citing them inline as numbered references [1], [2], and so on. The sources are listed beneath the answer as clickable links, so every claim is traceable back to where it came from. If the search returns nothing useful, the assistant says so plainly instead of inventing an answer.

Disabled in air-gapped mode
Web search reaches an external service, so it is turned off when the instance is running in air-gapped (zero-egress) mode. In that case it refuses with "Web search is disabled in air-gapped mode." Everything else (the assistant, writing helpers, estimates) keeps working on a local or self-hosted model key.

AI writing helpers

Beyond the assistant chat, AI shows up right inside your documents. There are three writing helpers, all running on your BYOK key. The mechanism lives here. The hands-on usage is on the Notes page, where these are surfaced as you write.

Page-anchored doc-assist

Doc-assist answers a question or carries out an instruction anchored to a single page, grounded on that page's live content. It reads the page title and current text (and an optional passage you have selected) as primary context, then answers or rewrites. When you ask it to write or edit, it returns clean Markdown ready to insert into the page, with no preamble and no code fences. Because it reads the page as it stands right now, it stays in sync with whatever you have typed, not a stale snapshot.

In-editor text transforms

Select text and apply a transform. The assistant returns only the rewritten text, with no commentary, so it drops straight back into your document. The available transforms are:

TransformWhat it does
RephraseRewrites the selection for clarity and flow while preserving its meaning.
SummarizeCondenses the selection into a concise summary.
ExpandAdds detail, examples, and explanation to the selection.
Fix grammarCorrects grammar, spelling, and punctuation while keeping your meaning and tone.
TranslateTranslates the selection into a target language you choose.

The generate block

The generate block creates new content from an instruction, optionally using the surrounding document as context. It behaves like a writing assistant embedded in the editor: you give it an instruction ("draft a rollout plan in three phases"), it can read the current page for context, and it returns clean Markdown ready to drop in, no preamble, no fences. Use it to start a section from a prompt rather than a blank cursor.

Targeted AI features

A few places in the product use AI for one specific, bounded job rather than open-ended chat.

AI estimate suggestion

On a work item, you can ask the AI to suggest an estimate. It reads the item's title and description and the project's configured estimate scale (smallest to largest), then picks the single most appropriate value and snaps it to a real point on that scale. The suggestion is always a value your project actually uses, never an off-scale number, so you can accept it with one click or adjust. If the model's answer cannot be matched to the scale, it returns no suggestion rather than a wrong one. A project with no estimate scale configured returns a clear error instead.

Natural language to PQL, and the AI chart

  • Natural-language filtering lets you describe the slice of work you want in plain English and have it translated into a PQL query. See the Views page for how to use it.
  • The AI chart turns a question about your workspace metrics into a real chart: the model chooses a metric and a breakdown dimension from a fixed set, then Elliptic computes the chart from your actual data rather than letting the model invent numbers. See the Dashboards page for how to use it.

Glossary-aware meeting summaries

Your organization has its own vocabulary, product names, internal codenames, acronyms, terms of art, and Elliptic can teach the model that vocabulary so it uses your words instead of generic ones. Each term is a term plus a definition, managed under Settings → Vocabulary and described in detail on the AI agents & automations page.

When a meeting is summarized, Elliptic assembles your terms into a compact glossary block and injects it into the model's system prompt, with an instruction to spell those terms exactly as written and to prefer them over similar-sounding alternatives. The result is that the model gets your internal names right, transcribes your codenames correctly, and stops "helpfully" normalizing your jargon into something generic. You maintain the term list in one place, and meeting summaries pick it up automatically.

Accountability: every call is on the record

Because the AI spends your money on your provider, Elliptic keeps an honest ledger of what it did. Two surfaces give you that visibility: a run log of individual calls, and a credit usage view of the monthly total. A guardrail on structured answers keeps the model from corrupting your data when it misbehaves.

The AI run audit log

Every outbound call to your provider creates an AI run recording exactly what happened. Admins review the full history, newest first, under the AI run list. It is your audit trail and your usage view in one place.

FieldWhat it tells you
Provider & modelWhich account and which exact model handled the call.
PurposeWhat the call was for: a meeting summarize, or a chat call (which covers the assistant, web search, writing helpers, estimates, charts, proposed actions, and routing).
Input / output tokensWhat the call consumed, for tracking cost against your provider bill.
StatusRunning, succeeded, or failed.
ErrorThe provider's message when a call fails (a bad key, a rate limit, an unknown model), kept for debugging.

Crucially, a failed call is still recorded, with its error preserved, so an erroring key or a misconfigured model never silently vanishes from the ledger. Whatever the AI does, including what your agents do, flows through this same log, so nothing is a black box.

Per-seat AI credit usage

Alongside the raw log, Elliptic tracks AI usage against a simple per-seat credit pool. Each AI run counts as one credit, and the org's monthly allowance is 500 credits per billable seat. The usage view shows credits used this calendar month, the limit derived from your seat count, and the remaining balance (plus a percent-used figure), so you always know how much of the month's AI budget the org has spent. The pool resets at the start of each calendar month.

The structured-output guardrail

Several features ask the model for structured output rather than prose: a chart spec and a proposed Build action. For these, Elliptic asks the provider to constrain its reply to a strict schema (using OpenAI's JSON-schema response format or Anthropic's forced tool use) and then validates the reply with Pydantic. If the model still returns something off-spec, Elliptic re-asks exactly once with a pointed correction. If the second attempt is still invalid, the feature falls back to a safe default instead of acting on garbage: the AI chart drops to a sensible default chart, and a proposed action is refused with "The assistant could not produce a valid action." A misbehaving model degrades gracefully. It never corrupts your data.

How it all fits together

  • One key powers everything. Connect an OpenAI, Anthropic, Ollama, or custom key once, and the assistant, web search, writing helpers, estimates, charts, and your agents all run on it, on your account, at your cost.
  • One switch gates it. The workspace AI toggle turns all of it on or off in a single move, with a clear error when it is off.
  • The assistant respects your role. Ask is read-only. Build proposes a change, you confirm, and it executes as you through normal permissions.
  • Answers are traceable. Web search cites numbered sources, and the glossary keeps meeting summaries speaking your organization's language.
  • Nothing is a black box. Every call lands in the run log with its model, purpose, tokens, and status, counts against a visible per-seat credit pool, and structured answers are validated with a single safe re-ask.