Sapphire and the path to general artificial intelligence

At Zvena we are working on Sapphire, the architecture of an AI system meant to join a language model, the choice of actions, long-term memory and the checking of what it has learned into one working loop. The project is now at its third stage: we are assembling the components into a whole. Our hypothesis is that this organisation may help a system work on its own for longer and use the experience of earlier attempts. How this approach relates to AGI still has to be established by experiment.

With this entry we open the Zvena research centre. Here we will take technologies apart, explain our decisions and discuss questions we cannot yet answer. We start with the biggest one: how far are we from artificial general intelligence, and what exactly has to change to get closer to it?

Conceptual diagramThe crystal and the working loop · 12 s. Conceptual diagram: generating, acting, checking and remembering make up one working loop. The crystal is the project's visual image, not a model of how it computes. The picture: A blue cut gemstone assembles from its facets in 3D and turns slowly. Four labels appear around it in a clockwise loop joined by arrows: Generate (blue disc) at the top, Act (violet diamond) on the right, Verify (ochre tick) at the bottom and Remember (teal square) on the left; the arrows light up in turn, back to Generate.

This entry has 19 short explanatory animations. The labels inside the videos are in English, and each has an explanation beside it. The formulas and the main points can be read without playing any video. The key videos are open in the text; the extra mathematical walk-throughs open on request.

What getting closer to AGI means

AGI, Artificial General Intelligence, usually means a system with broad intellectual abilities comparable to a person's. But a good conversation, a high test score and a day of independent work test different things.

The paper Levels of AGI proposes looking at the breadth of abilities and the level of performance, and discussing autonomy separately. It is a useful starting point: one impressive skill is not enough to describe a whole system.^[1]

For this diary it helps to keep four questions in view: how varied the tasks are, how reliable the result is, whether experience carries over to new conditions, and how much human involvement is needed. We write them down as a map of observations:

\mathbf{c}=(B,R,T,A).

Here B is the breadth of tasks, R reliability, T transfer of experience and A autonomy. This is our explanatory scheme, not an accepted AGI index. We do not suggest adding these values up into a "percentage of intelligence readiness": each of them first needs tasks, scoring rules and measurements.

Watch the walk-through · Four dimensions of ability · 18 s

Conceptual diagramFour dimensions of ability · 18 s. Breadth of tasks, reliability, transfer of experience and autonomy are four separate questions. This scheme gives the system no scores and measures no percentage of AGI readiness. The picture: The formula c = (B, R, T, A) at the top. Below, four raised cards appear one by one as their letter in the formula turns blue: B Breadth — range of task types it handles; R Reliability — how consistently it succeeds; T Transfer — lessons carried to new tasks; A Autonomy — acting with no human step. No numbers.

Another useful view is the task-difficulty horizon. METR estimates it by the time a human expert spends on a task. For example, the horizon at 80% success is the difficulty at which the system reaches that reliability according to the evaluation model. It is not the length of the system's continuous work.^[2]

H_{\rho}=\sup\{h:\Pr(\mathrm{success}\mid h)\geq\rho\}.

In this explanatory notation h is the human duration of a task and ρ the chosen level of reliability. It assumes the probability of success falls as difficulty grows within the evaluated set. Different reliability requirements give different horizons.

Watch the walk-through · The task-difficulty horizon · 24 s

Worked exampleThe task-difficulty horizon · 24 s. A teaching curve: at a 50% success requirement the horizon is 4 hours of human work, at 80% about 2.336 hours. This is not how long an AI works without stopping. The picture: The formula for H_ρ at the top. Below, axes: x is the hours a human expert needs for the task, 0 to 10; y is the probability of success, 0 to 1. A falling S-shaped blue curve. A violet dashed line at ρ = 0.5 meets it above h = 4; a second at ρ = 0.8 meets it above h ≈ 2.336. Read-outs on the right give both horizons.

So the question "how many months are left until AGI?" does not yet have an answer that can be derived from any single result. Our research question is narrower and more concrete: which changes help a system cope with harder tasks, learn from checked experience and keep its quality over long work?

What happens inside a language model

For an autoregressive LLM, generating an answer can be written as a sequence of conditional probabilities:

p_{\theta}(y_{1:n}\mid x)=\prod_{i=1}^{n}p_{\theta}(y_i\mid x,y_{<i}).

x is the input context, yᵢ the next token and θ the model's parameters. A token can be a word, part of a word or another unit of text encoding. Each next piece depends on the available context and on the continuation already built.

This formula describes the generation of a sequence. For the system to take an action in the outside world it also needs tools, rules for calling them and handling of their results.

Watch the walk-through · Generating a sequence of tokens · 22 s

Worked exampleGenerating a sequence of tokens · 22 s. A worked example: the tokens ready, for and review extend the context one after another. Conditional probabilities of 0.6, 0.5 and 0.8 give 0.24 for the whole chosen sequence. The bottom line shows the product being built up step by step. The picture: The product formula at the top. Below, the prompt tokens 'The report is' in grey boxes. Three answer tokens appear one at a time — 'ready', 'for', 'review' — each in a blue box with its probability under it (0.6, 0.5, 0.8), while a teal bracket labelled 'context' grows to cover the prompt and every earlier token. The bottom line builds 0.6 × 0.5 × 0.8 = 0.24.

One of the main mechanisms of the Transformer is attention. In the simplified notation for a single head it looks like this:

\operatorname{Attention}(Q,K,V)=\operatorname{softmax}\!\left(\frac{QK^{\mathsf T}}{\sqrt{d_k}}\right)V.

The matrices Q, K and V hold queries, keys and values. Matching queries against keys sets the weights by which the values are mixed. Scaling by the square root of the dimension dₖ helps keep the size of the scores in check before the softmax. This is a computational mechanism, not a measure of human attention.^[3]

Attention on its own does not organise a project's long-term memory or the checking of an action's consequences. Those functions belong to the design of the whole system around the model.

Watch the walk-through · Attention, step by step · 28 s

Worked exampleAttention, step by step · 28 s. One attention head on three made-up tokens: the score matrix, scaling, a row-by-row softmax and mixing the values V. Numbers on screen are rounded to two places; the computation uses more precision. The picture: The attention formula at the top. Q times K transpose gives the 3 × 3 score matrix [[1,0,1],[0,1,1],[1,1,2]]. Divided by √2 it becomes [[0.71,0,0.71],[0,0.71,0.71],[0.71,0.71,1.41]]. Softmax row by row, each row framed in turn, gives [[0.40,0.20,0.40],[0.20,0.40,0.40],[0.25,0.25,0.50]], each row summing to 1. Times V it gives the 3 × 2 result [[0.80,0.60],[0.60,0.80],[0.75,0.75]].

The idea behind Sapphire

We are studying a single architecture in which generation, decision-making and work with experience are linked by a shared state. The language model helps interpret the task and form options. The decision loop sets the next step. The environment returns a result. Memory keeps what may be useful later.

By Decision models in this entry we mean the functional loop that chooses actions. The specific algorithm cannot be read from that name. Language models and decision models also do not have to be mutually exclusive architectures: Decision Transformer, for example, applies a Transformer to sequences of states, actions and desired reward. This is an example from the literature, not a statement that Sapphire uses it.^[4]

To describe our idea, we introduce the state of the system:

\begin{aligned} s_t&=(g,o_t,h_t,M_t),\\ s_{t+1}&=\mathcal{F}_{\theta,\phi}(s_t,a_t,o_{t+1}). \end{aligned}

g is the goal, oₜ the current observation, hₜ the system's working context, Mₜ long-term memory and aₜ the action. In the accompanying diagram θ stands for the language model's weights and φ for the settings of the control loop, the harness. This notation describes the system loosely; it does not claim a separate trained decision model exists. The working context here should not be confused with the hidden state of a single neural-network layer.

The function F describes the whole system's transition to the next step. In the diagram it passes through interpretation, choosing an action, executing it and checking the result. This is a conceptual formalisation, not a published implementation specification.

Loops of this kind have predecessors. In ReAct a language model alternates reasoning and actions, using the results of its interaction with the environment. So the research value of Sapphire has to be judged by what our particular organisation of the loop gives in practice.^[5]

Conceptual diagramThe architecture of Sapphire · 32 s. Conceptual architecture: the state holds the goal, the observation, the working context and memory. After an action the environment returns a result; the check shapes the next step and what is written to memory. There is an exit when the goal is reached or the budget is spent. The picture: Two formulas at the top: s_t = (g, o_t, h_t, M_t), labelled goal, observation, context, memory, and s_{t+1} = F_{θ,φ}(s_t, a_t, o_{t+1}). Below, a 3D board seen from above at an angle: blocks for LLM (blue), Choose action (violet), Tool & environment (grey), Verify (ochre) and Update context (grey) joined in a loop by arrows on the floor. A teal Memory block in the middle sends a 'read' arrow to Choose action and receives an 'update' arrow from Verify. An Exit block on the right is reached from Verify: goal reached or budget spent.

To explain the choice of the next step, we can use this objective:

a_t^{*}=\underset{a\in\mathcal{A}_{\mathrm{allowed}}(s_t)}{\operatorname{argmax}}\;\bigl[U_{\phi}(s_t,a)-\lambda\,\operatorname{Cost}(a)\bigr].

The system considers the allowed actions, estimates their expected usefulness U and takes cost into account. The coefficient λ sets the weight of costs. The formula states a design principle: usefulness has to be weighed against expense. It does not mean a separately trained usefulness function is already implemented or predicts outcomes accurately.

Watch the walk-through · Choosing the next action · 24 s

Worked exampleChoosing the next action · 24 s. Teaching scores with λ = 0.8: ask the user, 4.6; query the API, 7.4; search memory, 5.6. Deleting, which is not allowed, is excluded in advance. These scores are not measurements of Sapphire. The picture: The formula at the top. A table of four actions with usefulness U and cost. 'Delete old records' is framed in red, crossed out and dimmed as not allowed before any score is computed. For the other three, a violet bar shows U − 0.8 × Cost: Ask the user 4.6, Query the API 7.4, Search memory 5.6. The 7.4 row is framed as chosen.

By continuous work we mean the ability to move from one checkable step to the next and to resume work from a saved state. Such a process has to be able to finish when the goal is reached, the budget is spent, no useful action is left or clarification is needed. Endless execution is not a success in itself.

Why a system needs long-term memory

In our current work we use a component the team calls Tensor Agent Memory Database, and part of the Hermes Agent agent harness. A harness here means the execution infrastructure: how calls to the model, the tools and the state are organised. These components are the basis of the build; their presence does not yet prove self-learning or AGI.

The official Hermes documentation describes notes kept between sessions and procedural skills. That is important context for us: experience can be reused at the level of the system, without changing the language model's weights.^[6]

One way to look for a fitting memory is to compare the query's vector with the vectors of the records:

\begin{aligned} \operatorname{sim}(q,e_m)&=\frac{q^{\mathsf T}e_m}{\lVert q\rVert\lVert e_m\rVert},\\ \mathcal{R}_t&=\operatorname{TopK}_{m\in M_t}\operatorname{sim}(q_t,e_m). \end{aligned}

qₜ represents the current query and eₘ a memory record. For cosine similarity both vectors must be non-zero. TopK returns the few records with the highest similarity. This illustrates a possible search; it is not a statement about the internal algorithm of the named database.

A similar record, however, may be wrong, out of date or valid for one project only. So useful memory needs a source, a time, a scope and a way to be corrected. Similarity helps find a record; whether it is true is checked separately.

Watch the walk-through · Searching long-term memory · 24 s

Worked exampleSearching long-term memory · 24 s. A teaching search by cosine similarity gives about 0.99, 0.71 and −0.39. Of the two records found, one has to be rejected because of an unconfirmed source, its age and a different API version. All records and dates are made up. The picture: Two formulas on the left above a small plane with a blue query arrow q and teal arrows e1, e2, e3. On the right, three raised cards with similarity 0.99 'Orders sync by API polling', 0.71 'Webhooks retry every 5 min' and −0.39 'Meeting notes template'. The top two are framed as recalled. Then each recalled card shows its source, date and scope: the first a verified run log from 2026-09-14 for Client A, API v2 (ochre tick); the second an unchecked chat message from 2024-03-02 for API v1 only (red cross).

To explain how checked experience is written down, a rule helps:

M_{t+1}=\begin{cases} \operatorname{Upsert}(M_t,e_t),&\operatorname{Verified}(e_t)=1,\\ M_t,&\operatorname{Verified}(e_t)=0. \end{cases}

Upsert means adding or updating a record, Verified the result of a given check. A real system will also need conflict handling and a way to undo wrong records. The formula states the intended principle, not a guarantee of error-free memory.

Watch the walk-through · Writing down checked experience · 22 s

Worked exampleWriting down checked experience · 22 s. The check first rejects an unconfirmed record, then accepts a change to the existing record about sync. The number of records stays at three: Upsert updates the right key instead of creating a duplicate. The picture: The cases formula at the top. On the right, a stack of three raised memory cards: Client A · sync — webhook (v1), Invoices — PDF, monthly, Reports — every Monday. A candidate card 'Client A · export: FTP upload' meets the check, gets a red cross and slides away; memory is unchanged. A second candidate 'Client A · sync: API polling, 15 min' gets an ochre tick and merges into the matching card, which now reads 'API polling, 15 min (v2)'.

In what sense a system can learn

"Self-learning" has several meanings here. A system can save a fact, refine an instruction, create a reusable procedure or change how it chooses actions. Each of these can change its later behaviour. Changing the parameters of the neural network itself is a separate process.

\begin{aligned} \text{memory update:}\quad &M_{t+1}\ne M_t,\qquad\theta_{t+1}=\theta_t;\\ \text{weight training:}\quad &\theta_{k+1}=\theta_k-\eta\nabla_{\theta}\mathcal{L}(\theta_k;D_{\mathrm{checked}}). \end{aligned}

The first line shows memory changing while the LLM's weights stay the same. The second shows the usual gradient update: η sets the step size, L is the loss function and D_checked the checked training data. The second line is there to explain the difference; with it we do not claim that Sapphire already retrains its weights on its own.

What matters to us is the observable result: after useful experience the system should do better on relevant new tasks. Replaying a saved answer tests memory but does not yet show that a skill carried over.

Conceptual diagramSystem memory and weight training · 30 s. On the left, memory M changes while the weights θ stay the same; on the right, gradient training is explained. The teaching curve uses L(θ) = (θ − 2)² + 0.5 and η = 0.3. This video does not claim Sapphire trains its own weights. The picture: Two panels. Left, 'Memory update': M_{t+1} ≠ M_t, θ_{t+1} = θ_t; a stack of memory cards gains a new teal card while a grid of weight cells stays the same, tagged 'weights unchanged'. Right, 'Weight training': θ_{k+1} = θ_k − η ∇L(θ_k; D_checked); a dot steps three times down a U-shaped error curve. A note says this is explained, not claimed as working in Sapphire.

What zeros and ones can explain

Binary notation makes it easy to show how a system narrows its set of actions. Take four example actions in a fixed order: read, delete, verify, write. The availability mask might look like this:

b_t=(1,0,1,1),\qquad (1011)_2=11_{10}.

A one means the action is available at the current step, a zero that it is excluded. The value 11 is the ordinary decimal form of this bit sequence. What the mask means is set by which position stands for which action.

Watch the walk-through · A binary mask of actions · 18 s

Worked exampleA binary mask of actions · 18 s. The order of actions is fixed: read, delete, verify, write. The mask 1011 excludes deleting. As a binary number it equals 11 in decimal. The picture: The formula b = (1, 0, 1, 1) at the top. Four raised tiles: read, delete, verify, write, with the bits 1, 0, 1, 1 under them. The delete tile is dimmed with a red cross: blocked. Place values 8, 4, 2, 1 appear under the bits and the line 1·8 + 0·4 + 1·2 + 1·1 = 11 builds, ending in (1011)₂ = 11₁₀.

If, before the mask is applied, the probabilities of actions are given by the distribution π, the available options can be renormalised:

\widetilde{\pi}(a_i\mid s_t)=\frac{b_i\,\pi(a_i\mid s_t)}{\sum_j b_j\,\pi(a_j\mid s_t)}.

With a positive denominator the excluded action gets zero probability, and the rest again add up to one. If the denominator is zero the formula does not apply: the system has to take a planned exit, such as stopping or asking for clarification.

This is a teaching example of controlling actions. Such a mask is not proof of learning on its own, and it does not replace the permission check on the side of the tool being run.

Watch the walk-through · Masking probabilities · 24 s

Worked exampleMasking probabilities · 24 s. The mask turns the distribution (0.1, 0.6, 0.2, 0.1) into (0.25, 0, 0.5, 0.25). The edge case of a zero denominator is shown separately: division does not apply, and the process needs a planned exit. The picture: The masking formula at the top. Bars for read, delete, verify, write at 0.1, 0.6, 0.2, 0.1. The mask 1, 0, 1, 1 appears under them; the delete bar drops to 0. The sum of what is left, 0.4, is shown, and the bars rescale to 0.25, 0, 0.5, 0.25. Finally a red case: if every allowed probability is 0 the sum is 0, division is impossible, and two exits are shown: stop, or ask for clarification.

A concrete scenario to test the idea

In the accompanying illustration the requirements document changes: webhook sync is replaced by an API request every 15 minutes. The list has three tasks that involve the webhook and one more task unrelated to the integration.

The system first rewrites the three related tasks for the new way of syncing. Then the check finds an exception: under Client B's terms, its webhook has to keep working. The wrong change to that task is undone, and the saved rule is refined to include the exception. The other two tasks stay switched to the API request.

An example like this lets us ask checkable questions: does the system find the related records, can it undo an unsuccessful action, and does it carry the refined rule over to a new task? It matters to measure both the initial mistake and the quality of its correction.

This is an illustrative scenario, not a description of an experiment that was run. The client names, tasks and intervals here are made up. A real case has to come with the original task, the observed actions and an independent check of the result.

Illustrative scenarioA changed requirement and an exception · 32 s. An illustrative scenario: after the requirement changes, the system first changes three tasks, then finds the exception for Client B, restores its webhook and refines the rule. This is an example of correcting a mistake, not a recording of a product feature. The picture: Top left, a raised requirement card: 'webhook' struck out, replaced by 'poll the API every 15 min'. Below, four task cards T-14 to T-17. The three that mention webhooks are framed in blue as outdated and rewritten for polling; on the right a check list ticks T-14 and T-15. A teal memory card saves the rule 'Sync: API polling every 15 min'. Then T-16 for Client B is restored to 'Client B webhook alerts' with an ochre tick — webhook still valid — and the rule card gains 'except Client B: webhook stays'.

The third stage of the work

According to the team's report of 28 October 2026, Sapphire is at its third stage: assembling the components into one project. The animations in this article explain the idea; they are not a recording of Sapphire at work. This publication gives no numerical results of internal trials.

The plan of work can be shown in four steps:

Step	What it involves	What lets us move on
1	Define the tasks and the research hypothesis	There are observable criteria of success
2	Prepare the generation, action and memory components	Their roles and ways of working together are clear
3	Assemble the single loop	State and results pass between the components
4	Run comparative trials	There are reproducible results and an analysis of errors

This is a map of the project's content; it does not replace a report that each step is complete. The main question of the current integration is whether the single loop can keep a useful link between the goal, the action, the result and the next decision.

Team status reportThe project's third stage · 18 s. As the team reports, the current stage is assembling the single loop. The four nodes are a map of the work's content; they are not a scale of AGI readiness. The picture: Four raised cards in a row joined by arrows: 1 Hypothesis, 2 Components, 3 Unified loop, 4 Comparative trials. The third card is framed in blue and tagged 'current stage, as reported by the team'. There are no dates and no progress bars.

What published experiments already show

In the 2023 Reflexion study the authors compared plain generation with a system that uses feedback and text memory. Their Table 1 gives these results for Python:^[7]

Benchmark	Base GPT-4	Reflexion	Difference
HumanEval	80.1%	91.0%	+10.9 pp
MBPP	80.1%	77.1%	−3.0 pp

These are historical results of specific configurations, not measurements of Sapphire. The metric is called pass@1, but the Reflexion process includes internal checking and corrections before the final score, and the compute costs differ. A gain on one set sits next to a loss on another.

Published experiment · 2023A published comparison: Reflexion · 26 s. A comparison published in 2023, Python, pass@1: HumanEval 80.1% → 91.0%; MBPP 80.1% → 77.1%. These are results of the Reflexion paper, not of Sapphire; the checking processes and compute costs differ. The picture: A horizontal bar chart on a 0 to 100 % scale with two groups. HumanEval: GPT-4 80.1 % (grey bar, ring marker), Reflexion 91.0 % (teal bar, square marker), difference +10.9 pp. MBPP: GPT-4 80.1 %, Reflexion 77.1 %, difference −3.0 pp in red. A note reads 'Not Sapphire results; different verification processes and costs', and the source line cites arxiv.org/html/2303.11366v4, Table 1.

There is also a more recent test of what an agent harness contributes. In a METR research note of 13 February 2026, comparing Codex and Claude Code with the harnesses METR uses, on GPT-5 and Opus 4.5, showed no statistically significant advantage in task horizon. This is a limited experiment with the stated models and settings, not a general conclusion that harnesses are useless.^[8]

What we take from these papers is a research hypothesis: the quality of feedback, memory and loop control deserves to be measured on its own. A more complex system may bring a gain, a loss or just extra cost.

How we want to compare Sapphire

To test what each component contributes, we need variants of the system in which one essential element changes: the base LLM with the same tools; the loop without long-term memory; the loop with memory; the loop with memory and checked updates to procedures. This is a plan for the comparison, not the results of a finished experiment.

The main metric is the share of tasks that fully pass a check set in advance:

\widehat{p}_{v}=\frac{1}{N}\sum_{i=1}^{N}Y_i^{(v)},\qquad Y_i^{(v)}\in\{0,1\}.

v stands for the variant of the system, N for the number of tasks and Yᵢ for the result of the check. Partial completion can be scored as well, but it must not quietly turn into full success.

The difference is better computed on the same tasks:

\widehat{\Delta}=\frac{1}{N}\sum_{i=1}^{N}\left(Y_i^{(\mathrm{new})}-Y_i^{(\mathrm{base})}\right).

This paired comparison shows on which tasks the new variant helped or got in the way. The estimate needs its uncertainty beside it, for example a confidence interval from a paired bootstrap over tasks. Repeated attempts at one task should not be counted as new independent tasks.

Watch the walk-through · A paired comparison of variants · 30 s

Worked exampleA paired comparison of variants · 30 s. Teaching data for four tasks: the base variant solved 2 of 4, the new one 3 of 4. The paired difference is +25 percentage points, although one task got worse. Four made-up tasks are not enough to conclude there is an improvement. The picture: Two formulas at the top. On the left, a grey panel of tuning tasks marked 'used to tune, not scored'; on the right, a table of four held-out tasks. Row 'base': tick, cross, tick, cross, giving p̂ = 0.5. Row 'new': tick, tick, cross, tick, giving p̂ = 0.75. A third row shows the per-task differences 0, +1, −1, +1 and Δ̂ = +0.25 = +25 pp.

Tasks used for training and debugging have to be kept apart from the held-out set. Testing transfer will need new conditions, including exceptions to rules that were useful before. The systems being compared must have the same base model, the same access to tools and budgets set in advance. If extra compute alone could explain a gain, a separate control with a comparable budget is needed.

Cost is part of the result too:

C_{\mathrm{success}}=\frac{\sum_{i=1}^{N}C_i}{\sum_{i=1}^{N}Y_i},\qquad\sum_iY_i>0.

Cᵢ is the full cost of an attempt, including a failed one. If there are no successes, the cost per success is undefined. It should be shown together with time, tokens, the number of tool calls, human interventions and repeated mistakes.

Watch the walk-through · The cost of a success · 20 s

Worked exampleThe cost of a success · 20 s. A teaching cost: four attempts at one unit each give 2 units per success with two successes, and about 1.333 with three. The cost of failures counts; with no successes the ratio is undefined. The picture: The formula at the top. Two rows of four coin tokens, one per attempt, each marked with a tick or a cross: base tick, cross, tick, cross; new tick, tick, cross, tick. Beside them: 4 / 2 = 2 and 4 / 3 ≈ 1.333. A final red line: if no attempt succeeds, the denominator is 0 and the cost per success is undefined.

When an improvement can be accepted

Being able to propose a new instruction does not mean the instruction is useful. So in the conceptual scheme an update to the system goes through an evaluation:

\mathcal{S}_{k+1}=\begin{cases} \mathcal{S}'_k,&\operatorname{EvalPass}(\mathcal{S}'_k,\mathcal{S}_k)=1,\\ \mathcal{S}_k,&\operatorname{EvalPass}(\mathcal{S}'_k,\mathcal{S}_k)=0. \end{cases}

S′ is the proposed version of the system, for example with a changed procedure. EvalPass combines requirements chosen in advance for quality, acceptable regressions and costs. Passing this check is empirical ground for accepting the change under the given conditions, not proof that it is useful for ever.

Tuning again and again on one set gradually turns it into training material. So a serious claim of improvement needs independent checks and a saved earlier version to return to.

Conceptual diagramChecking a proposed improvement · 26 s. A conceptual check of updates: the first procedure passes the checks and becomes version 4; the next fails the regression check, so version 4 is kept. This is a rule for accepting a candidate, not a guarantee of ever-rising quality. The picture: The cases formula at the top. A version track at the bottom starts at v3. A candidate card 'new retry procedure' moves through three gates — quality, no regressions, cost — and gets three ochre ticks; it becomes v4 on the track. A second candidate 'shorter prompts' passes quality but gets a red cross at 'no regressions'; it is rejected and an arrow returns to v4.

Why long work stays hard

In a long chain, a small chance of error at each step can noticeably lower the overall reliability. If success requires every critical step to succeed, the chain rule of probability applies:

\begin{aligned} \Pr(E_1\cap\cdots\cap E_n)&=\prod_{i=1}^{n}\Pr(E_i\mid E_1,\ldots,E_{i-1}),\\ \text{if all conditional probabilities equal }p:\quad P_n&=p^n,\\ 0.99^{100}&\approx0.366,\qquad 0.999^{100}\approx0.905. \end{aligned}

The last numbers are a teaching calculation with equal conditional probabilities, not a measurement of any model. In a real process errors are linked to each other, some can be fixed and some steps are not critical. The formula shows why checking intermediate results and recovering from failures matter for long work.

The end of the animation looks at one more teaching mechanism: detecting and correcting errors. Let c be the share of wrong steps that were both detected and fully corrected. If the check does not spoil results that were right to begin with, the effective probability that a step succeeds is:

p_{\mathrm{eff}}=p+(1-p)c=1-(1-p)(1-c).

With p = 0.99 and c = 0.9 this gives p_eff = 0.999. This is a conditional calculation, not a measurement of Sapphire: successful detection together with full correction is folded into the one value c. New errors the check itself might introduce are not counted in this simple model.

Worked exampleThe reliability of a long chain · 28 s. A teaching model: with the same conditional chance of success of 0.99 per step, a hundred steps give about 36.6%, with 0.999 about 90.5%. The last part shows the conditional effect of correcting 90% of errors with a reliable check; it is not an actual property of the system. The picture: Two formulas at the top. Axes: number of steps n from 0 to 100, chance the whole chain succeeds from 0 to 100 %. A grey curve for p = 0.99 falls to 36.6 % at n = 100; a blue curve for p = 0.999 stays high and ends at 90.5 %. Then the formula p_eff = 1 − (1 − p)(1 − c) with c = 0.9 and an arrow from the grey end point to the blue one: checking and recovery lift the chain.

That is why we treat Sapphire as research into how AI work is organised. It will have to be judged by how it finds errors, uses experience and copes with new tasks within given limits.

What the next entry should bring

Our long-term goal is to study the path to more general and more independent artificial intelligence. We allow that joining generation, decisions and checked experience may turn out to be part of that path. Whether such a system would be enough for AGI does not follow from our concept today.

Outperforming people at particular tasks is also not the same as outperforming them across the whole range of intellectual work. To discuss that meaningfully, the tasks, conditions, reliability and cost of the comparison have to be defined. A timeline of a few months or years remains a guess, not a result of this work.

Sapphire's next real milestone is reproducible experience: a task, a starting configuration, a saved rule, a new situation and a measurable result. Most interesting is the case in which the system first made a mistake, then used checked experience and could explain the limits of where it applies. Material like that will give this research diary what we are starting it for: observations that can be discussed and checked.

Sources

Morris et al. Levels of AGI for Operationalizing Progress on the Path to AGI. 2023, with later revisions. https://arxiv.org/abs/2311.02462
METR. Task-Completion Time Horizons of Frontier AI Models. The page is marked as no longer actively updated; the last stated update is 8 September 2026. https://metr.org/time-horizons/
Vaswani et al. Attention Is All You Need. 2017. The attention formula is in section 3.2.1. https://arxiv.org/html/1706.03762v7
Chen et al. Decision Transformer: Reinforcement Learning via Sequence Modeling. 2021. https://arxiv.org/abs/2106.01345
Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. 2022–2023. https://arxiv.org/abs/2210.03629
Nous Research. Hermes Agent: Persistent Memory and Skills System. Documentation viewed on 28 October 2026. https://hermes-agent.nousresearch.com/docs/user-guide/features/memory and https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
Shinn et al. Reflexion: Language Agents with Verbal Reinforcement Learning. 2023, version 4, section 4.3, Table 1. https://arxiv.org/html/2303.11366v4
Jurkovic, METR. Measuring Time Horizon using Claude Code and Codex. Research note of 13 February 2026. https://metr.org/notes/2026-02-13-measuring-time-horizon-using-claude-code-and-codex/

All research

Product

Use cases

Open source

Help