A Harness Does Not Get Better at Its Job
In July we described an engineering harness as the layer around coding agents that holds an objective together: the approved plan, the bounded workers, the review, and the continuity between runs. That is still what Skyflo is. It is also, by construction, a system that does not improve.
A harness that has run a hundred missions is exactly as good at the hundred and first as it was at the first. The conventions you repeated, the gate your team runs before every commit, the agent that keeps winning a certain kind of task: all of that lived with you. The harness held each objective carefully and then let go of what it had seen.
Skyflo 1.1.0 changes that. Skyflo is now a HyperAgent: it learns from the missions it completes, carries what they teach into future work, turns workflows that prove themselves into reusable Skills, and can change the way it routes work, inside a boundary it cannot change.
The short version is one sentence. Skyflo improves how it improves.
That is a strong claim, so the rest of this post is about what it means precisely, what ships today, and where the edges are.
Three Loops, Three Layers
It helps to separate three things that are easy to blur.
An agent does the work. It reads the code, runs the commands, and writes the change.
A harness holds the work. It owns the objective, decides who does which part, keeps the evidence attached, and makes sure the thing that produced a change is not the only thing that judges it.
A HyperAgent improves the process by which it improves. It does not only produce better outputs over time; the mechanism that decides what it learns and how it routes work is itself something it can change, under rules it cannot change.
In Skyflo that last part is not a metaphor. It is three layers with hard edges, written into the runtime:
- Task layer. Memory, procedures, and Skills. Skyflo proposes them from finished work; an independent judge admits them.
- Meta layer. The routing policy: the weights Skyflo uses to score which agent and model should lead a mission, and the thresholds a change has to clear. Skyflo proposes a new policy; a held-out judgment admits it.
- Root layer. Authority and approvals, credential custody, spending limits, redaction, kill switches, evidence hashing and signing keys, the gate code itself, and the holdout rule. Nothing proposes changes here. A proposal does not have a field for any of it. Only a signed Skyflo release changes the root.
Everything below is one of those three layers.
Learning From the Missions It Completes
In June we argued that memory should be a proposal, never an automatic write. A mission proposed candidates, a person accepted or dismissed each one, and only accepted memory was retrieved later. That rule was right for a system that could not yet tell good evidence from bad. It had a cost we underestimated: when every lesson waits in a queue for a click, the queue becomes a chore, and a chore that is skipped teaches the system nothing.
1.1.0 replaces "you approve everything" with the evidence decides.
When a mission completes, a consolidation pass reads what happened and drafts what it taught. Each draft cites its sources. A build, test, or procedure hint is kept on its own only when every one of its admission conditions holds, and the condition that matters most is where the claim came from: either your own words, stated in the mission, or a successful execution that actually ran the command the claim names. A card whose evidence Skyflo observed is kept. Anything inferred, anything that conflicts with what is already known, and anything whose scope is unclear waits for you in Needs attention, where you can keep it, correct its wording before keeping it, or dismiss it.
One rule deserves its own paragraph. A draft whose only sources are content an attacker could influence (tool output, repository files, previously retrieved memory) is quarantined. It is recorded for diagnosis and never offered as a one-click keep. That is why the consolidation input always carries the person's own words: a repository cannot teach Skyflo something simply by containing text that says so.
You stay in control of the whole loop. Use memory in tasks decides whether anything learned reaches a mission. Learn automatically decides whether Skyflo learns at all; with it off, a mission writes no memory events of any kind. Every record can be removed, and every record links to the mission and files that produced it.
Two limits are worth stating plainly. Memories you add by hand from the Memory page are saved and listed, but they are not given to tasks yet. And erasing a learned memory removes it from every view and every task, while the append-only activity log still holds its original entry.
An engineering lesson from getting here. The first version of consolidation gave the whole job twenty-five seconds: spawn a harness, open a hidden session, stream back a bounded answer. On a loaded machine that is not enough, and the failure was silent. The session produced a valid draft, the deadline cut it off mid-token, both retries did the same, and the job recorded a generic technical failure that read like a broken provider. On one signed staging build, five of seven consolidation jobs failed this way. The fix was two minutes and an honest timeout reason. On a later build, twelve of twelve jobs completed on the first attempt. A learning system that fails quietly is worse than one that does not learn, because it looks like it is working.
From Memory to Skills
A procedure hint is scoped to one repository by design. If a mission establishes that this repository runs npm run check and then npm test before a commit, that is this repository's habit, and it stays a memory there, however many times it happens.
The interesting observation is the second repository. When a mission in a different repository verifies the same sequence of commands, that is evidence of a reusable workflow rather than a local habit. That is the moment Skyflo proposes a Skill.
Three design decisions make that work:
- A workflow is identified by its commands, not its wording. Two people describing the same gate in different words corroborate each other. When claims disagree about an aside, they corroborate on the ordered steps they share.
- The Skill's name and body are a pure function of the command sequence. That sounds like a detail. It is what makes independent endorsement possible at all: two agents doing ordinary work would never agree on prose, but they can arrive at the same content hash.
- The judge is never the improver. The agent that proposed the Skill cannot approve it. The same proposer repeating itself endorses nothing. A Skill is admitted only when a second, independent harness arrives at the same content, or when you keep it yourself.
Here is what that looked like on our own signed staging builds before release. Two clean repositories each stated the same commit gate in ordinary work, in different words, and never mentioned a Skill. Both procedures admitted themselves. The second mission, run by Claude Code, proposed a Skill. An Antigravity turn doing the same ordinary work in that repository reached the identical content hash, and the gate admitted it. Nobody reviewed anything. A later mission that named the Skill loaded its body as a mandatory instruction and ran both commands before committing, although its own instruction asked for neither. A mission in an unrelated repository saw nothing, learned nothing, and proposed nothing. One revert took the Skill out of the catalog, while the record of it stayed.
You call a Skill from the / menu in the repository it belongs to. Specialists never activate Skills on their own, and a Skill too large for the instruction budget is reported as such rather than loaded in part.
Improving How It Improves
When you let Skyflo choose which agent and model lead a mission, it scores every eligible pair and picks one. The scoring is a policy: a set of weights and the thresholds a candidate route has to clear. In 1.1.0 that policy is the meta layer, and Skyflo is allowed to change it.
The rules are strict because this is the part that could go wrong most quietly:
- A new policy is proposed from one split of past routes and judged on another. The split is decided by a salted hash the proposer cannot influence, so it cannot choose its own exam.
- It is adopted only if it strictly beats the policy in force on the held-out routes. Ties keep the parent.
- It may tighten a threshold and never loosen one. It may not touch the holdout rule or the evaluation suite; a proposal that tries is refused before it is scored.
- One promotion per cycle. At every later cycle the policy in force is judged again against the holdout as it now stands, and it is halted automatically when it no longer beats the policy it replaced.
We want to be exact about the current result. On the routing record we had at release, every route had completed, most leads had been pinned by hand, and there was no failure for a better policy to learn from. The loop reproduced every recorded choice under the shipped weights and proposed nothing. That is the correct outcome. Improvement across generations is proven at the test boundary on synthetic records; a real promotion needs real routed failures. A self-improving system that reported an improvement without that evidence would be exhibiting exactly the failure this design exists to prevent.
So the honest statement is the one the product makes: Skyflo can improve how it routes work, and it will only do so when the evidence says the change is better.
The Part That Never Learns
A system that changes itself is only as trustworthy as the things it can never change. Skyflo's root layer is enforced in code, and five rules hold at every layer:
- No self-granted authority. A proposal cannot widen a threshold, touch the evaluation suite, or carry anything that reads as an authority grant. Skill bodies are screened for credentials and authority language on their exact recorded content.
- The judge is never the improver. Routing is judged on routes the proposer did not see; Skills are judged by an independent harness or by you.
- Every promotion is content-hashed and lineaged. Each change records its parent. Reverting is one action, and the parent is in force the moment it returns.
- The archive is never pruned. Refusals and halts are recorded beside promotions, with their reasons. A subject that has already been judged is not proposed again, which is what makes a revert a decision rather than an invitation to try again.
- One promotion per cycle, with automatic halt on regression.
All of this is visible. The Memory page has an Improvements tab that lists every change Skyflo has made to itself, newest first: what changed, who proposed it, who judged it, and one Revert on the change in force.
What This Does Not Mean
It is worth being clear about what a HyperAgent is not, because the word invites more than it should.
- Skyflo is not training on your code. Nothing here changes model weights. What changes is memory, Skills, and a routing policy, all stored on your Mac.
- Nothing it learns leaves the machine. Generations are local. The only thing that crosses is a signed catalog from Skyflo, and a new one retires every local generation built on the old one.
- It does not relax your approvals. A proposal can only express memory, Skills, or the routing policy, so learning cannot reach plan approval, the read-only reviewer, or any permission gate.
- Some things are still Planned. Organization-wide shared memory and evidence-gated mission completion are not part of 1.1.0, and the status page says so.
Why This Is the Release That Changes the Story
Our harness thesis ended on a sentence we still believe: the constraint is increasingly coordination across systems, agents, and time. The first two parts were always Skyflo's job. The third, time, was mostly yours. You carried what the last mission taught into the next one.
With 1.1.0, Skyflo carries part of that itself. It keeps what the evidence supports, turns what has proven itself twice into something reusable, and can adjust how it assigns work, while the things that decide what it is allowed to do stay outside its reach.
A harness holds the work. A HyperAgent gets better at holding it, and shows you how.
The release notes list what shipped. How Skyflo learns between missions walks through memory and Skills, and how it works shows the improvement loop inside the mission loop.