The engine
under the Operators

The engine
under the Operators

Sophona is not a wrapper around a model. It is a platform that plans the work, executes it with real tools, judges its own results against evidence, and stops for a human at the points you choose.

Day one

You never start with an empty platform

There is no blank canvas and no onboarding maze. From the first login you have an assistant that already knows the product and does the work with you: set up an Operator, design a process, build an application, wire an RPA robot, explain what a setting does. You are never the person who has to learn the tool first.

Ask for an Operator

It configures one for you — persona, skill map, model, voice and channels — and you talk to it a minute later.

Ask for an app

It writes the app, hosts it on your instance and hands you the address. No deployment ticket, no DevOps.

Ask for an automation

It designs the process from your description and validates each block while it builds, not after the fact.

Sophona · Command Center

Hello, Michał

What are we working on today?

Ask Sophona anything...
The whole thing

Everything a company runs on, in one place

Sophona is not a tool you add to a stack. It is the stack: the people, the conversations, the software you have not bought yet, and the work itself — under one login, on your own machines. There is nothing to integrate, because nothing was apart.

A team, staffed today

Operators with real roles, a place in the org chart and calendars of their own — and your people alongside them, taking over whenever it matters.

OperatorsOrg chartCalendarsHuman handoff

Somewhere to talk

Meetings, internal chat and a phone number in the same system — and Operators that show up in the channels your company already uses.

Sophona MeetInternal chatTelephonyTeamsGoogle Chat

Software you never pay for separately

A CRM, a board, a tracker, a client portal. Describe it in a sentence and it exists — hosted on your own instance, behind your own login, in minutes.

CRMKanbanTrackersPortalsForms

Task automation

Processes, desktop robots, API calls, documents and schedules — the same environment that holds the team and the tools also does the job.

WorkflowsDesktop RPAAPIDocumentsSchedules

And no, we are not asking you to leave Google or Microsoft — we like both. Sophona connects to Google Workspace and Microsoft 365: mail, calendars, Teams and Google Chat. Your Operators work inside the channels your company already lives in, rather than beside them. What you build here fills the space between those tools that until now was filled by people copying things across.

How it compounds

You asked for sales. You got a sales department.

  1. 1

    You describe the job: an Operator that finds companies worth talking to, writes the first email and picks up the phone when someone replies.

  2. 2

    It needs somewhere to put them. So while you are still describing the role, the CRM is built around it — contacts, stages, owners, notes — hosted on your instance, behind your login, in minutes.

  3. 3

    Your people need to see it. A board appears next to it, showing the same pipeline the Operator is working, so a human can reorder it, correct it or take a conversation over.

  4. 4

    Nothing had to be integrated, because nothing was ever separate. The Operator, the CRM and the board are one system that happens to have three faces.

Solo Enterprise

One person can now run what used to need a department — not because the work got smaller, but because hiring, buying tooling and wiring it all together stopped being three separate projects with three separate bills.

Minutes, not quarters

No procurement, no vendor comparison, no integration project, no seat licences for a tool half the team will never open. You say what you need, it appears where everything else already is.

A story from our company

A job description went in. A colleague came out.

Our CEO wanted an assistant, so she did what anyone does before hiring a person: she wrote down the duties and the requirements. Then, instead of posting the ad, she handed the document to Sophona.

  1. What she wrote

    A document meant for a person

    The scope of the role, what it has to keep track of, what it must never let slip. Written the way you write for a human being — nothing about software, nothing about configuration, no idea yet which tools would end up involved.

  2. What Sophona asked

    The interview ran the other way round

    Sophona read the document and asked about everything it did not say: what the assistant should be called, which parts of the job needed more detail, and which tools the work would actually touch. The same conversation you would have with a new hire on their first day — only this time the new hire was asking.

  3. What got built

    Built from the answers, then given the keys

    The assistant was assembled from that conversation and connected to the accounts the job runs on: the mailbox, the calendars, chat, Sheets and Docs. Not an integration project — simply the accesses any new colleague is given in their first hour.

  4. What nobody asked for

    The work needed somewhere to land

    Then came the part that was not in the document. Work that gets done has to be recorded somewhere, so Sophona built an application for the two of them — something CRM-shaped, but cut to this particular pair rather than to a market segment.

Connected on day one

The accesses a colleague gets

Her mailbox
Calendars
Chat
Sheets
Docs

Nothing here was an integration in the project-plan sense. These are the same accounts a person joining the company would be added to, granted to somebody who happens not to be a person.

And one thing more

The application nobody asked for, and everybody needed

A place for the assistant to file what she has handled, and a view where the CEO sees it summarised instead of reported. Two sides of one small application, built because the work needed it — not because someone put it on a requirements list.

How it works now

They work as a pair. Things stopped sitting around waiting for somebody to notice them, and nothing has to be chased any more, because following up is now somebody's actual job — and that somebody does not forget, get busy, or go quiet for three days. The blockers that used to live in 'I'll get to it' are simply not there.

What it is

Not another automation tool

You do not have to migrate anything. Sophona can start from scratch, or extend, connect, run and develop the workflows, RPA and applications you already have — and add a persona, a memory and a phone number on top of them.

Your situation
No automation yet
Start with an Operator, an application and one process — not a two-year programme.
You already run workflows
Add conversation, long-term memory and execution on top of what already works.
You already run RPA
Give the robot a goal, context, a phone number, meetings and human control.
Your decisions happen in meetings
The Operator moves from what was agreed to what actually gets done.
The workplace

Every surface, one system

Same Operator, same memory, same governance — whichever surface the work happens on. Click through the panels on the right; they all work.

The engine that does the work

A loop that plans the job, executes it with real tools and judges its own results against evidence — not a chat with tools bolted on.

  • Intent prebrief runs in parallel: a cheap model decides whether words are enough or a tool is needed, at no extra latency.
  • Task plans with observable completion conditions and an automatic verification stage — 'three files exist', not 'done'.
  • An independent arbiter grades every stage on evidence and can send the Operator back to work.
  • Long-term memory as a graph, an organisation graph for routing, and semantic search across your documents.
  • Three model tiers with a fallback ladder, prefix caching and cost accounting per session.
Sophona · Ava · task plan
Task plan

“Reconcile last month's invoices and flag anything that does not match.”

Pull last month's invoices
API · finance system
Match invoices against purchase orders
process · reconcile
Match invoices against purchase orders (retry)
process · reconcile
Escalate mismatches over 5 000
threshold rule
Verification stage
added automatically
Arbiter · evidence

Every stage is graded on recorded evidence — a file, an API result, a search result — never on the Operator's own description of what it did.

The execution loop

It checks its own work

An Operator is not a chat with tools bolted on. It is a loop that decides whether the work was really done — judged on evidence, not on its own description of what it did. This is the hardest part of the product to copy.

Intent prebrief

A separate, cheap model evaluates the request in parallel with the main one and answers one question: does this need a tool, or are words enough? Because both run at the same time, the check costs no extra waiting.

Task plan

A complex request is split into stages, each with its own step budget and an observable completion condition — not 'done', but 'three files with test cases exist'. A verification stage is added automatically.

Execution with real tools

Processes, desktop RPA, API calls, files, the phone. Every result is recorded as evidence rather than summarised away.

Arbiter

After each pass an independent model judges the stage on the evidence: done, continue, evidence missing, failed, or wait for a human. A claim without evidence gets challenged.

Kept-word check

If a turn ended without a single tool call while the prebrief said one was needed, the system sends it back with 'do it now instead of describing it'. The check runs after the reply, in the background, so nothing slows down.

Result and trace

The task list updates live, a reasoning panel shows what the Operator is doing right now, and the outcome is stored with everything it was based on.

Three guards keep an autonomous loop from spinning: a step budget per stage, a deadlock counter that force-closes a stuck stage with whatever it managed to gather, and repeat detection that forces a fresh check instead of another identical pass.

Memory

Context that survives the conversation

Long-term memory is a graph

Nodes for people, topics, agreements and milestones; edges for relations and dates. That is why an Operator can say 'we agreed this last week, that other thing was three months ago' instead of treating everything as equally fresh.

It grows on its own

Summaries produced while a session compacts feed the graph with topics as the conversation runs, so memory builds without anyone cataloguing it by hand.

Organisation graph

People, roles, teams and relations, used for routing: the Operator knows who owns an area and can hand a case over — and a manager can correct that decision.

Semantic knowledge

Documents go into a vector store and are read by meaning. Web results are treated as evidence and face the same arbiter judgement as everything else.

Private by design

Your own space. Nobody else in it.

Sophona is not a service where your company becomes a row in someone else's system. Every customer gets their own instance — their own machines, their own applications, their own database. Nothing is pooled, nothing is shared, and nothing you build sits on a hosting platform we simply resell.

Your own machines

Automations and applications run on workers assigned to you alone, never in a shared pool competing with other companies for capacity.

Apps that live in your space

Every application built here gets its own isolated container inside your instance, with its own address and its own lifecycle — not a tenant slot on a public platform.

A database nobody else touches

Your records, your Operators' memory and your documents sit in a database of your own. No shared tables, no neighbours.

Our cloud, or your building

Run it in our cloud or install it on your own servers — Linux or Windows. Same product, same behaviour, your choice of where it lives.

How it is built

Technical Architecture

Sophona is an agentic automation platform built around a Skill Map graph. The graph dynamically gates context so the Operator has access only to skills relevant to the current business path — instead of a flat prompt stuffed with every tool. Each skill is a self-contained workflow runtime that can call AI in real time (planning, tool routing, retries) and apply Mind Inject procedures at the right moment, giving you full control over how the Operator behaves without hardcoded logic.

Skill Map is a graph (context gating)

Instead of a flat list of tools, Sophona uses a skill graph. At any moment the Operator sees only skills relevant to the current business path — reducing context and improving reliability.

Each skill is its own workflow runtime

Every skill is an executable workflow that can call AI in real time (planning, tool routing, retries) and apply Mind Inject inside the skill — not only at the top-level Operator.

Mind Inject (full business control)

You can inject procedures and policies at runtime — globally, per business path, or per skill. This enables deterministic, auditable behavior without hardcoding logic.

Sophona Architecture
Skill Map graph + runtime skills
Interaction Layer
One mind, many channels
Phone Operator
Voice in/out · SIP/Twilio
Web Widget
Embed · React/JS
Desktop Widget
Windows/macOS
API / iPaaS
REST · Webhooks · Queues
Core (Graph + Control)
AI Mind (Router)
Interprets intent · selects path in the graph
Skill Map Graph (Context Gate)
Activates only relevant skills for the business path
Mind Inject
Policies/procedures at runtime (global/path/skill)
Scheduler
Cyclic · conditional · event triggers
Execution & Integrations
Skill Workflow Runtime
Each skill can plan · call AI · retry · verify
Autonomous Web
Click · Navigate · Forms
Desktop Automation
Apps · OS UI · RPA-like
Google Workspace / APIs
Gmail · Calendar · CRM/ERP · iPaaS

Skill Map is a graph used for context optimization: only relevant skills are exposed to the Operator at a given time.

Skills
Micro-skills ↔ Structured workflows
Spectrum: how “big” a skill can be
Micro-skill (atomic) · e.g. click / input / wait / read elementStructured workflow (stable) · variables · conditions · deterministic steps
Micro-skill building blocks
UI.Click(selector)
Low-level action
UI.Input(selector, value)
Controlled input
UI.WaitFor(text/element)
Sync / stability
UI.Read(element)
Extract evidence
Hybrid: stable + smart

Deterministic steps control the process.

AI is called only for:

  • routing within the skill
  • interpreting unstructured input
  • choosing next step when ambiguous
  • generating a safe text response
deterministic flow + AI only where needed
Structured workflow skills
Variables
state + parameters
Conditions
if/else branches
Retries & timeouts
no brittle flows
Verification
evidence + audit

Key idea: you can stay fully deterministic (no hallucinations) or allow autonomy — all by choosing which skills exist and how they connect.

Under the hood

The technology that makes it run

Sophona is not a thin layer over somebody else's model API. The parts that decide whether this is fast, cheap and reliable are our own: the graph that gates context, the vision engine that drives real desktops, and the small models that run on our own hardware.

Skill Map graph

Context gating

Tools are not a flat list. A directed graph decides which skills exist at all on the current business path, so the model picks from a handful of relevant actions instead of a hundred plausible ones.

Vision engine for RPA

Our own computer vision

The desktop worker does not live or die by selectors. Our own vision models find controls on the screen the way a person does — which is why automation also works on remote desktops, virtualised sessions and software that exposes nothing to automate.

Inference on our own metal

ONNX runtime

The small models that never stop running — intent prebrief, classification, element detection, embeddings — are ours and execute locally in milliseconds, without leaving the instance and without costing a token.

Vector store

Semantic index

Documents, memory nodes and collected evidence sit in one semantic index, so a question is answered by meaning rather than by keyword — and the same index serves both an Operator's memory and your knowledge base.

Memory graph

Temporal graph

People, topics, agreements and milestones as nodes; relations and dates as edges. Time is part of the structure rather than a column, which is what lets an Operator weigh what is recent against what is settled.

Model orchestration

Three tiers, live failover

Every step is routed across model tiers and vendors by what it is actually worth, with prefix caching, a fallback ladder and cost accounting per session underneath.

Real-time voice

Streaming, barge-in

Speech in and out streams continuously instead of taking turns, so an Operator can be interrupted mid-sentence and can keep talking while a workflow is still running behind the call.

Single-tenant runtime

Isolated per customer

Services, workers, applications and database run in an instance belonging to one customer — in our cloud or on your servers — with short-lived tokens between services and no shared data path anywhere.

Security, privacy and governance

Nothing happens outside your rules

An Operator that remembers your organisation is only useful if you can say exactly where that memory lives, who can reach it, and what the Operator is allowed to do on its own.

Not used for training

Your conversations, documents and records are not used to train models. Providers are called through our abstraction layer and can be chosen per Operator.

PII vault

Sensitive data recognised in a conversation is replaced by tokens before it is written to the database and before it is sent to a model, then substituted back on read. Enabled per Operator.

Session versus permanent knowledge

Documents uploaded for a single conversation are cleared when the session closes, so they never pollute the permanent index. Organisation knowledge is stored separately and shared deliberately.

Encrypted secrets

Credentials and keys are stored encrypted under a system key and decrypted only by an authorised call at execution time. The Operator never sees the raw value.

Authenticated integrations

You authorise a service once and the Operator calls its API without ever holding the credentials — tokens are injected server-side, in flight.

Roles and skill maps

Administrator and service roles are separated and entry points are gated by role. An Operator only sees the tools assigned to its skill map and its channel; administrative tools are panel-only, never available through the widget or the phone.

Human in the loop

Approval points inside a process, a clarification mode, a stop on exception, operator takeover of a live conversation and a hard stop button. Value thresholds decide what an Operator may close by itself.

Audit trail and cost accounting

Session logs with stages, tool calls, evidence, errors and timings, plus prompt and response tokens, cache hits and reasoning cost per session and per model.

Isolation and hosting

Kubernetes deployment with separated development and production environments, short-lived tokens between services, and single-tenant instances for enterprise: separate runtime, separate data boundary. Cloud or self-hosted.

Regulatory posture

Built to operate under GDPR and the EU AI Act, with regulatory packages handled for telephony numbers in the countries that require them.

Several of these controls are configured per Operator rather than switched on globally. We walk through the exact settings for your case during the audit, before anything touches production data.

Want to see it running on your process?

We can walk your technical team through the loop, the memory graph and the governance model — on your data, under NDA.