AltFn
Contact us
How it works · Sapphire

How Sapphire Works

Sapphire records what your agents and tools do, builds a map of your company from it, learns how work flows, and briefs every agent before it acts. Then, team by team, what that changes.

AltFnSix steps, nine teams

Connect: your agents and your tools, recorded as traces

A plugin records each agent session: Claude Code, Codex, Devin and Sapphire’s own. Connectors sync the systems your teams use. Every record is scrubbed of secrets and kept as it was produced, under the permissions of the system it came from.

Map: who and what your company is made of

People, agents, services, applications, accounts and processes, linked by what the records say: who owns what, what depends on what, who worked on what. Nothing is overwritten, so any past week can be reconstructed.

World model: how work actually flows

From the map over time, Sapphire learns which steps follow which, what each step needs, and what tends to go wrong. It starts with simple counts and moves to a learned model only when that does better on weeks it never saw.

What agents get: briefings, Decision Contexts and hand-offs

  • Briefings. Before a session starts: what to read first, the likely next step and a budget.
  • Decision Contexts. Before a move that matters: the next step, the evidence and how sure the answer is.
  • Hand-offs. The work itself, given to the agent for that part of the company, acting with the asker’s access.
  • API and MCP. Any agent that can call an API or an MCP server can ask. Answers include only what the asker may read.

Guard: autonomy earned one kind of move at a time

Every move an agent makes is checked against your policy before it runs. A kind of move earns the next level from the yeses it gets; one no starts it over. Payments, deletions and account changes always wait for a person.

  • Assist. Answers and drafts; people act.
  • Shadow. Works beside people and is compared with what they did.
  • Approve. Asks before each move.
  • Self-driving. Moves on its own; people watch and can undo.

Improve: every outcome comes back

Each night, outcomes flow back into the model. A change to an agent is kept only when it does better on cases it has not seen, and a person approves it before it is used.

Sapphire for Engineering

Your Coding Agents Start Briefed and Spend Fewer Tokens. Claude Code, Codex and Devin start each session with what sessions like it needed: the files to read first, the likely next step and a budget. Fewer searches and re-reads, and more of the context window left for the work.

Use cases

  • Briefed coding sessions. Each session starts with the files to read first and the likely next step, from sessions that did the same kind of work. Measure: tokens per finished session.
  • Checks before a merge. Before merging, the agent asks. It learns which tests caught problems in changes like this one. Measure: reverted changes.
  • Tickets handed to a service. The agent for a service reproduces the bug, fixes it and opens the pull request for review. Measure: first-try rate.

What your agents get

  • Briefings. At the start of every session and prompt: the files and tickets the next steps will touch, ranked by how often agents here needed them.
  • Decision Contexts. Before a merge or a deploy, an agent asks. It gets the next step, the past sessions that went wrong and how sure the answer is.
  • Hand-offs. Give a ticket to the agent for a service. It works in the cloud with your access and opens the pull request for your review.
  • A card on every pull request. Reviewers see the outcome, the tests and what the agent was briefed with, without opening anyone’s session.

The parts Sapphire finds

Repositories, Services, CI pipelines, On-call rotations, Incidents. Sapphire finds them from your code host, tickets and the sessions your agents run. Each has an agent its owner approves, which starts by only answering.

Where it learns

Coding agents, Code host, Ticketing, CI, Chat, Incident tool, each read under its own permissions.

What you measure

  • Tokens per finished session. The bill, for work that got done.
  • Tool calls per session. Wrong turns and re-reads.
  • First-try rate. Savings that didn’t cost quality.
  • Reverted changes. What had to be undone.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Connect the coding agents your team uses. Briefings run in shadow first, then go live for the team once they beat a plain search on your own past weeks.

Sapphire for Product & Design

Product and Design Agents That Know What Customers Asked For. Your product and design agents start briefed: which requests and bugs belong to your area, what similar features and flows needed, and what has to happen before a release. Learned from tickets, calls, analytics, design files and your code host, under each system’s own permissions.

Use cases

  • Customer signal to the roadmap. Feature requests and bugs from tickets, calls and usage, linked to the product area that owns them. Measure: requests linked to the roadmap.
  • Specs and designs grounded in the past. What similar features needed, the components and services they touched, and where users struggled after they shipped. Measure: rework after review.
  • Release readiness. The steps a release takes here, from flags to docs to the support briefing, and what went wrong last time. Measure: issues after release.

What your agents get

  • Customer signal, linked. Feature requests and bugs from support, sales calls and usage, grouped by the product area that owns them.
  • Grounded specs and designs. What similar features needed, the components and patterns they used, and where users struggled after they shipped.
  • Release routes. The steps a release takes here, from flags to docs to the support briefing, with their owners.
  • Hand-offs to engineering. A scoped change goes to the agent for the service that owns it, with the spec attached.

The parts Sapphire finds

Products, Product areas, Features, User flows, Design system, Releases. Sapphire finds them from your roadmap, code host, tickets and the threads where product decisions are made. Each has an agent its owner approves, which starts by only answering.

Where it learns

Roadmap tool, Design tool, Ticketing, Product analytics, Call notes, Code host, Chat, each read under its own permissions.

What you measure

  • Requests linked to the roadmap. Customer asks that reached an owner.
  • Rework after review. Spec and design changes asked for after review.
  • Issues after release. Problems in the first week.
  • Time from request to ship. For the asks that made it.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick one area and its next release. Sapphire links its customer requests and maps how its designs and releases ship, then briefs your product agent in shadow first.

Sapphire for IT & Security

Access and Change Requests That Follow Your Real Process. Your IT and security agents get the route a request actually takes here: who signs off, in what order, and which shortcuts get reversed. Learned from your service desk, identity provider and chat, under each system’s own permissions.

Use cases

  • Access to sensitive data. The data owner signs off, then a read-only grant. Requests that skip the sign-off are the ones reversed later. Measure: requests reversed.
  • Change approvals. The approvals a change needs, in order, and what broke the last time a change like it went out. Measure: approvals skipped.
  • Onboarding and offboarding. Every system in the order that worked before, with the owner of each step named. Measure: time to complete.

What your agents get

  • The route, not the pile. A request for a sensitive dataset goes to its data owner first, then a read-only grant. The agent gets that route, not twenty old tickets.
  • Approvals in order. Before a change ships, the agent knows which approvals it needs and what broke the last time a change like it went out.
  • Owners named. Requests that touch several systems follow the order that worked before, with the owner of each step named.
  • Every move checked. Each move an agent makes is checked against your policy and logged. Locked moves always wait for a person.

The parts Sapphire finds

Applications, Access processes, Identity groups, The change board, Service desk queues. Sapphire finds them from your service desk, identity provider and the threads around them. Each has an agent its owner approves, which starts by only answering.

Where it learns

Service desk, Identity provider, Data warehouse, Chat, Change calendar, each read under its own permissions.

What you measure

  • Time to grant. From request to the right access.
  • Requests reversed. Grants that had to be taken back.
  • Approvals skipped. Steps the route says were missed.
  • Tool calls per request. What each request costs to handle.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick the access requests for one system, such as your data warehouse. Sapphire learns its route from past requests and briefs your agent in shadow first.

Sapphire for Support & Success

Support Agents That Know Where an Issue Goes Next. Your support and success agents start each ticket briefed: which product or team owns it, what fixed it last time and when to escalate. Sapphire works alongside your help desk, not in place of it.

Use cases

  • Escalation routing. An issue goes to the team that owns it the first time, with what that team will ask for attached. Measure: tickets handed back.
  • Context on every ticket. Past fixes, open incidents and the account’s history, limited to what the person asking may read. Measure: time to resolution.
  • Bugs handed to engineering. A confirmed bug goes to the agent for the service that owns it, with the reproduction attached. Measure: reopened tickets.

What your agents get

  • Context first. Past fixes, open incidents and the account’s history, limited to what the person asking may read.
  • The right owner. An issue goes to the service or team that owns it the first time.
  • Account agents. An agent for each key account answers renewal and health questions from your CRM, tickets and calls.
  • Engineering in the loop. A confirmed bug goes to the agent for the service that owns it, with the reproduction attached.

The parts Sapphire finds

Products, Key accounts, Escalation paths, Help desk queues, Known issues. Sapphire finds them from your help desk, CRM and the engineering systems your tickets reach. Each has an agent its owner approves, which starts by only answering.

Where it learns

Help desk, CRM, Call notes, Ticketing, Chat, each read under its own permissions.

What you measure

  • Tickets handed back. Escalations that went to the wrong place.
  • Time to resolution. From first contact to fixed.
  • Reopened tickets. Fixes that didn’t hold.
  • Tokens per resolved ticket. What each answer costs.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick the escalations from one queue. Sapphire learns where they went and what resolved them, then briefs your support agent in shadow first.

Sapphire for Sales & Marketing

Sellers and Marketers Whose Agents Know What Happens Next. Your sales and marketing agents start briefed: what an account needs, who signs off on a deal, and which reviews a launch must pass. Learned from your CRM, calls and campaign tools, under each system’s own permissions.

Use cases

  • Account research before a call. Open tickets, usage, recent conversations and who decides, limited to what the rep may read. Measure: prep time per meeting.
  • Deal approvals. The approvers a discount or non-standard term needs, in order, and which deals stalled waiting for them. Measure: days in approval.
  • Campaign and launch reviews. The legal, brand and product reviews a launch has to pass, and what slipped the last time. Measure: launches on schedule.

What your agents get

  • Account briefs. Before a call: open tickets, usage, recent conversations and who decides, limited to what the rep may read.
  • Deal routes. A discount or non-standard term goes to the approvers it needs, in order, with what stalled similar deals.
  • Launch reviews. A campaign or launch gets the reviews it needs and a note of what slipped the last time.
  • Clean hand-offs. What a closed deal promised goes to the team that delivers it, so nothing is missed after the signature.

The parts Sapphire finds

Accounts, Deals, Campaigns, Launches, Territories. Sapphire finds them from your CRM, call notes, campaign tools and the threads where deals and launches are approved. Each has an agent its owner approves, which starts by only answering.

Where it learns

CRM, Call notes, Marketing automation, Chat, Email approvals, each read under its own permissions.

What you measure

  • Prep time per meeting. Time reps spend before a call.
  • Days in approval. How long deals wait on sign-off.
  • Launches on schedule. Reviews done before the date.
  • Promises missed after close. What delivery had to fix.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick the approvals for discounts or non-standard terms. Sapphire learns their route from past deals and briefs your sales agent in shadow first.

Sapphire for Operations & Finance

Cross-Team Processes Your Agents Can Follow End to End. Refunds, quote to cash, renewals and procurement cross four or five tools and teams. Sapphire learns the path work actually takes, so each agent knows the step it owns and what comes next.

Use cases

  • Refunds. The approvals a refund needs for its amount and reason, and the exceptions that tend to come back. Measure: exceptions.
  • Quote to cash. Each step from quote to invoice with its owner, and where deals usually wait. Measure: cycle time.
  • Renewals. What has to happen before a renewal date, and which accounts drift when a step is late. Measure: work handed back.

What your agents get

  • Workflows found, not drawn. Sapphire finds each workflow from the record of the work: its steps, their owners and where work waits.
  • An agent on each step. Each step has an agent its owner approves. The workflow’s coordinator passes work between them and never does a step’s work.
  • Exceptions first. Agents flag the requests that tend to be reversed before they move.
  • Rehearse a change. Try a new rule or a new agent against past months before it touches live work.

The parts Sapphire finds

Processes, Approvals, Vendors, Systems of record, Policies. Sapphire finds them from your finance, CRM and billing systems and the threads where approvals happen. Each has an agent its owner approves, which starts by only answering.

Where it learns

ERP, CRM, Billing, Procurement, Chat, Email approvals, each read under its own permissions.

What you measure

  • Cycle time. Start to finish, per workflow.
  • Exceptions. Requests that left the usual path.
  • Work handed back. Steps that had to be redone.
  • Steps that run without asking. Autonomy each step has earned.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick one process with a visible result, such as refunds. Sapphire maps how it runs today and puts an agent on one step in shadow first.

Sapphire for HR

HR Processes Your Agents Can Follow, Without Watching People. Your HR agents start briefed on how hiring, onboarding and policy requests actually move here: who approves, in what order, and where they stall. Sapphire models the processes, never the people: it does not score, rank or simulate anyone.

Use cases

  • Hiring pipeline. The steps a hire takes here, from requisition to offer, with who approves each and where candidates wait. Measure: days at each hiring stage.
  • Onboarding. Accounts, equipment, training and the first-week plan, in the order that worked, with the owner of each step. Measure: ready on day one.
  • Policy questions. Answers from the current policy, with its owner named, limited to what the asker may read. Measure: requests resolved without a ticket.

What your agents get

  • Hiring routes. Each requisition and offer goes to the approvers it needs, in order, with where similar hires waited.
  • Onboarding in order. Every account, device and training step a new hire needs, in the order that worked, with each owner named.
  • Policy answers. Answers from the current policy, with the person who owns it named.
  • Private by default. Anything about a person’s case goes only to people who can already see it in your HR system.

The parts Sapphire finds

Hiring pipeline, Onboarding, Leave and benefits requests, Policies, Offboarding. Sapphire finds them from your HR system, applicant tracking, service desk and the threads where approvals happen. Each has an agent its owner approves, which starts by only answering.

Where it learns

HR system, Applicant tracking, Service desk, Chat, Email approvals, each read under its own permissions.

What you measure

  • Days at each hiring stage. Where candidates wait.
  • Ready on day one. Accounts, equipment and plan in place.
  • Requests resolved without a ticket. Policy questions answered the first time.
  • Approvals skipped. Steps the route says were missed.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick onboarding for one team. Sapphire learns its steps and owners from past hires and briefs your HR agent in shadow first.

Contracts and Approvals That Follow Your Playbook. Your legal agents start briefed: which reviewers an agreement needs, which clauses drew pushback before, and when something has to go to counsel. Learned from your contract system, tickets and the threads where approvals happen, under each system’s own permissions.

Use cases

  • Contract review routing. An agreement goes to the reviewers its type, value and terms need, with the clauses that drew comments before. Measure: days in review.
  • NDAs and standard paper. Agreements the playbook already allows go out on the approved template; anything off it goes to counsel. Measure: standard paper rate.
  • Policy and compliance questions. Answers from current policies and past guidance, limited to what the asker may read, with the owner named. Measure: escalations to counsel.

What your agents get

  • Review routes. An agreement goes to the reviewers its type, value and terms need, in order.
  • Clause history. The clauses that drew comments on similar agreements, and how they were resolved.
  • Playbook first. Requests the playbook already covers are answered from it; the rest go to counsel.
  • Privilege respected. Material from privileged threads is shown only to people who can already read it.

The parts Sapphire finds

Contract types, Approval paths, Playbooks, Policies, Regulatory filings. Sapphire finds them from your contract system, ticketing and the threads where legal approvals happen. Each has an agent its owner approves, which starts by only answering.

Where it learns

Contract management, Ticketing, E-signature, Chat, Email approvals, each read under its own permissions.

What you measure

  • Days in review. From request to signature.
  • Standard paper rate. Requests closed on approved templates.
  • Escalations to counsel. Questions the playbook could not answer.
  • Clauses reopened. Terms revisited after signing.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Pick incoming NDAs or another standard agreement. Sapphire learns how they were reviewed and briefs your legal agent in shadow first.

Sapphire for Leadership

Line of Sight From a Decision to the Work Behind It. See how work actually moves across teams, where it waits and where agents help. Place agents where the evidence says they will, and watch autonomy grow one kind of move at a time.

Use cases

  • Where to place agents. The steps where work waits, loops or gets handed back, ranked by how much time they cost. Measure: time back each week.
  • Governing autonomy. Each kind of move with the level it has earned, and the switch to hold any of them. Measure: moves made without asking.
  • Why a metric moved. A metric traced back through the work, systems and agents that produced it. Measure: decisions traced to the work.

What your agents get

  • Line of sight. Trace a metric or a customer outcome back through the work, systems and agents that produced it.
  • Where agents help. The same model that briefs agents shows where work waits, loops and gets handed back.
  • Autonomy you can govern. Every kind of move earns its own level, from Assist to Self-driving, and you can hold any of them.
  • Savings you can see. Tokens, tool calls and time back for each team, never per person.

The parts Sapphire finds

Teams, Workflows, Agent budgets, Policies. The parts each team owns roll up into one picture of the company. Each has an agent its owner approves, which starts by only answering.

Where it learns

Every connected system, Every connected agent, each read under its own permissions.

What you measure

  • Moves made without asking. How much of the work is self-driving.
  • Time back each week. Hours agents finished for people.
  • Agent spend against cap. Usage, by team.
  • Changes rolled back. What autonomy cost.

Reported by team and by part, never per person, and only for groups of five or more.

Start here

Two or three teams that already run agents connect them first. Leadership sees the same numbers they do, as they come in.

Get a demoBack to the overview