AI agents & automations

What this page covers

Elliptic is Jira for your agents, and this page is about the agents themselves and everything they operate. It walks through AI agents (named members that live in your org), the budgets that bound what they cost, triage automations and skills that sort and route work, a glossary that fixes how AI features word things, the agent runner for scheduled scripts, the insight engine that suggests where work belongs, and the company brain that lets an agent catch up the way you would. Every AI feature runs on your org's own model key (BYOK), so the cost and the data stay with you.

AI agents: first-class members of your org

An AI agent (internally an "AI user") is a named, persistent assistant your org defines. Unlike a throwaway chat, an agent has a stable identity made of four things: a name, a provider, an exact model id, and a system prompt that fixes how it behaves. Think "Scribe" who summarizes meetings in decision-first bullets, or "Router" who explains how inbound work should be filed. Agents are managed under Settings → AI, in the AI users card, and from any connected AI client over the brain.

Because an agent is a member, it does not get a private side door. It runs on your org's BYOK key for its provider, and the actions it takes are the same member actions exposed over the company-brain MCP. Provider calls made through Elliptic (summaries, chat, and other AI features) are recorded as AI runs alongside the rest of your AI usage, each with its provider, model, token counts, and status. That is what makes the AI surface operable and accountable rather than a black box.

Create an agent

1. 1
   Open AI settings

   Go to Settings → AI. The AI users card sits below your provider keys. Click New AI user.
2. 2
   Name it

   Give the agent a clear, recognizable name like Scribe. Names are unique within your org.
3. 3
   Choose provider and model

   Pick the provider, then type the exact model id you want it to run on (for example gpt-5.2). The agent runs on your org's BYOK key for that provider, so you pick whatever model your key can reach.
4. 4
   Write the system prompt

   Describe what the agent does and how it should behave, for example "You summarize meetings for the team in tight, decision-first bullets." This instruction shapes every response the agent gives.
5. 5
   Create

   Save it. A new agent is active by default and immediately available to your org.

Edit, pause, budget, delete

• Edit. From Settings → AI, open an agent's Edit dialog to change its name, provider, model, or system prompt at any time, for example to move it onto a different model or sharpen its instructions.
• Pause and resume. Every agent carries an active flag. Pausing it stops it from acting without losing any configuration, and an inactive agent is clearly badged as Inactive in the AI users list. Over MCP this is pause_ai_user with active=false to pause or active=true to resume.
• Budget. Each agent can carry a monthly spend cap. Set it over MCP with set_ai_user_budget or through the AI users API.
• Delete. Remove an agent you no longer need. From the web UI, use the delete button on the agent. From a connected AI client, deletion is a deliberate two-step confirm: the first call previews the agent by name and returns requires_confirmation, and only a second call with confirm=true actually deletes it, so an agent is never wiped by accident.

Agent budgets: a guardrail against a runaway bill

An automated member that runs on a schedule or reacts to events could, in principle, spend without limit. Each agent can therefore carry a monthly spend cap, set as a number of cents per month. It is a Paperclip-style guardrail that bounds how much an agent is allowed to cost on your provider bill, so an agent left running cannot quietly drain your account.

Set a budget when you expect an agent to act unattended. Over the company-brain MCP this is set_ai_user_budget, which takes the agent and a budget_monthly_cents value, and like the rest of agent management it requires the agents:write scope.

Triage automations: stop sorting the same work by hand

An automation is a saved rule that applies actions to a task on a trigger. Instead of dragging every inbound bug into the right project and tagging it, you write the rule once and it runs every time the trigger fires. Automations live under Settings → Automations, and creating or editing them is admin-only.

Triggers: when a rule fires

Actions: what a rule does

A single rule can chain several actions, so one automation can label, route, and assign in one pass. Elliptic validates actions when you save the rule: a label that does not exist, a project outside your org, or an assign target who is not an org member (or who is a guest) is rejected up front, so a rule cannot silently misfire later. Every time a rule runs against a task, an automation_applied event is written to that task's activity, so you can always see exactly what touched it and why. Rules apply their actions defensively, so one bad action never breaks the rest of the pass.

Build an automation

1. 1
   Open Automations

   Go to Settings → Automations and fill in the new rule form.
2. 2
   Name and trigger

   Name the rule (for example "Route inbound bugs") and pick its trigger: on triage entry or on status change.
3. 3
   Add actions

   Add one or more actions (label, route, assign, set priority) and fill in each value. Use Add action to chain more in the same rule.
4. 4
   Save

   Save the automation. New enabled rules start running on their trigger immediately.
5. 5
   Toggle or remove later

   Each rule has an enable switch and a delete button. Disable a rule to pause it without losing it, or delete it when it is no longer needed.

Skills: reusable automations you invoke on demand

Sometimes you do not want a rule to fire on every trigger. You want to apply it deliberately, to the one task in front of you. That is a skill. A skill is the exact same kind of rule, with the same label, route, assign, and set-priority actions, but flagged so it does not run on its trigger automatically. Instead it sits ready to be invoked by hand.

When you are working the Triage queue, each item shows a Skills menu listing your enabled skills. Pick one and its actions apply to that task on the spot, with the run logged to the task's activity (a skill_executed event) just like an automatic rule. It is the fast way to say "file this the way I always file these" without dragging through menus. Only enabled skills appear in that menu, and when you have none the menu does not show at all.

Save a rule as a skill

1. 1
   Build the rule

   In Settings → Automations, create a rule with the actions you want to reuse.
2. 2
   Flip the skill switch

   Turn on "Save as an invocable skill." The rule now carries a Skill badge and stops firing on its trigger.
3. 3
   Run it from triage

   Open the Triage queue, find the task, open its Skills menu, and pick the skill. Its actions apply to that task on the spot.

Glossary: the words every AI feature should use

Your org has names the rest of the world does not: a product codename, a client's acronym, a workflow term you coined. The glossary (Settings → Vocabulary) is a list of those terms, each with a short definition. Reading the glossary is open to any member, and adding, editing, or deleting terms is admin-only.

The glossary is not just a reference page. Elliptic assembles your terms into a system-prompt block that is injected into AI calls, instructing the model to spell these terms exactly as written and to prefer them over similar-sounding alternatives. So once you define a term, AI features stop guessing and start using your vocabulary. The block is built from your terms in alphabetical order.

1. 1
   Open Vocabulary

   Go to Settings → Vocabulary. You will see the term and definition list.
2. 2
   Add a term

   Enter the term (for example a product or client name) and what it means, then add it. Terms are unique within your org.
3. 3
   Edit or remove

   Edit a term's definition or delete it. Changes flow into the next AI call.

The agent runner: scheduled scripts

The runner (Settings → Runner) is where you author reusable scripts in JavaScript or TypeScript and, optionally, give each one a cron schedule so it runs on its own cadence. Each script has a name, the code, an optional description, and an enable flag. A cron schedule must be a standard five-field expression (minute, hour, day of month, month, weekday), and one with the wrong number of fields is rejected when you save.

Open a script to review its execution history: the recent runs, each with a status (queued, running, succeeded, or failed), how it was triggered, and its output or error. This is your record of what a script did and when.

The insight engine: where work belongs and what relates to it

When a task or meeting needs filing, Elliptic can suggest the project it most likely belongs to. The routing is a heuristic: it scores your active projects by keyword overlap between the item's text and each project's name, key, and description. No model call is involved, which makes it fast and deterministic, and it is honest about thin evidence. When nothing matches, it returns a null suggestion with zero confidence rather than a confident guess; when something does, it returns the project, the route, and a confidence value derived from how far the best match leads the runner-up.

A companion surface aggregates related work for a task: it scans your other tasks, meetings, and notes, scores each by overlap with the task's title and description, and returns the strongest few of each kind (a task's source meeting is weighed heavily). The result carries explicit coverage, reported as "consulted N of M", plus a confidence that reflects how strong and how many the matches were. Both surfaces are built so the UI can show how much was actually looked at rather than implying certainty it does not have.

The company brain: catch up the way a member would

The brain is a set of cross-project tools that answer the questions you actually have when you sit down: what changed, where did we leave off, and what is on my plate. They read live from your tasks, notes, and activity feed, and they are reachable from any AI client connected to your Elliptic brain over MCP. This is the surface an agent uses to orient itself before acting, exactly as a person would.

Catch me up: what changed

Ask for everything that has happened in the org since a point in time and the brain returns the recent activity that landed after that moment: tasks created and moved, notes written, meetings imported, and more. This is the "I was out for three days, what did I miss" answer, scoped to a timestamp you choose. Over MCP it is brain_changes_since, which takes an ISO-8601 timestamp and returns the matching events from the activity feed.

Resume: where did we leave off

Point the brain at a project and it reconstructs the state of play: the in-flight tasks (work actually started), the most recent notes, and the latest activity on that project. It is the fastest way to reload context on something you have not touched in a while, without scrolling a board. Over MCP it is brain_resume, which takes a project id.

Open threads: what's on my plate

Ask for your open threads and the brain pulls together the tasks assigned to you, the tasks you created, and your triage queue, filtering out anything already completed or cancelled. It is a single honest snapshot of your outstanding work across every project. Over MCP it is brain_open_threads. All three brain tools require only the baseline brain:read scope.

Connecting and revoking agents

An agent reaches all of the above through Elliptic's connection layer, and you stay in control of what any connected app can touch. Access is granted in narrow scopes, not all-or-nothing. Read scopes like brain:read, agents:read, automation:read, and vocabulary:read are baseline. Most write scopes, including automation:write and vocabulary:write, are ordinary (granted but not flagged as sensitive), while a few like agents:write and agents:keys are elevated and granted deliberately. A client only ever gets the intersection of what it asked for and what you allowed.

Manage all of this under Settings → AI Access, which lists every connected app and device, the org it is connected to, and exactly which scopes it holds, with a one-click Revoke that cuts a client off immediately. For the full OAuth scope catalog, the connection flow, and revocation in detail, see the Company-Brain MCP page.

How the pieces fit together

• Agents are members. A named identity, a provider, a model, a system prompt, an optional budget, and the full member surface over MCP. They run on your BYOK key.
• Budgets bound the bill. A monthly cap in cents keeps an unattended agent from running away with your provider spend.
• Automations and skills remove busywork. Rules sort triage and status changes on autopilot; skills apply your filing logic by hand in one click. Both are validated on save and logged on every run.
• The glossary steers the words. Define your org's terms once and AI features spell them your way.
• The runner schedules scripts. Author JS or TS, attach a cron, and review run history, with the sandboxed runtime arriving later.
• The insight engine suggests, honestly. Heuristic routing and related-work aggregation report coverage and confidence instead of guessing.
• The brain reloads context. Catch-me-up, resume, and open threads give an agent (or you) the same situational awareness a member walks in with.