MeshiaBlog
The problemThe refereeJob cardsLeases
Continue
ByClick to copy Luke's emailandClick to copy Shiva's emailAugust 26, 2026

How we got long-running AI agent swarms to work

Our first swarms could do a lot, but they could also repeat work and lose the thread. Society is the small control layer we built to keep the team moving as one.

job = { owner, lease, budget, proof }Goalone outcomeJ-01J-02J-03Evidenceproof bundleReviewfinal check01 · define02 · assign03 · verify04 · review
Society control flowWe split one goal into owned jobs, collect their evidence, and review one result.

Our first swarm got loud fast

When we first added more agents, the screen looked busy and the work felt fast. Then we read the output. Two workers had done the same task. One key check had no owner. A polished answer came back with no proof.

The models were not the main problem. The team shape was. A long job needs memory, ownership, time, money, and a clear way to finish.

That changed our question. We stopped asking how many agents we could start. We asked what rules would help each extra agent make the final answer better.

We built a referee, not one more player

Society is not one more AI agent. It is the plain control layer around the agents. The workers still plan, write, test, and search. Society keeps the clock, budget, job list, and proof rules.

We think of it like a referee. The referee does not kick the ball. It starts play, watches the clock, marks a bad move, and says when the game is done.

This split made the system easier to test. We can change a model or tool while the same job card, lease, budget, and evidence rules stay in place.

Core idea

Let smart workers be creative. Keep ownership, money, time, and proof boring.

Each worker gets one job card

We give each worker one job card. It names the owner, goal, tools, time limit, budget, and proof that must come back.

The card also points to its parent job. Every small task has a place in the tree. If a worker stops, we can see the exact hole instead of reading a whole chat to guess.

The allowed tools live on the card too. A research worker cannot quietly turn into a system worker. We can let the model be creative inside a clear box.

  • One owner for each job.
  • One clear link to the parent job.
  • One allowed toolbox.
  • One time and cost box.
  • One list of proof to bring back.

Leases stop two workers owning one job

A worker holds a short lease while it works. A heartbeat keeps that lease alive. If the lease ends, we can give the job to a new worker.

We then fence the old worker. Its late tool call is blocked. Without that fence, an old worker and a new worker could both change the same file.

We use the same plain rule for budgets. Each run gets a fixed box for time, tokens, and cost. A worker can use its share, but it cannot act like the box has no bottom.

We split done from proven

A worker can say it is done. We still ask for an evidence card. That card can hold source links, test results, file changes, and open doubts.

Weak proof gets a low grade. Plain text with no clear record gets Grade D. A risky answer can go to a specialist even when the worker says it is finished.

This split made our runs much easier to read. Job status tells us what the worker did. Evidence status tells us what the team can trust.

One small rescue beats a full rewrite

When one job is missing, we do not ask the whole team to start again. We send one helper to fix that gap.

The helper gets a narrow card. It sees the failed job, the missing proof, and the small part it may change. After the repair, we read the result one more time.

This keeps the rescue small. It also leaves a simple story: here was the gap, here was the repair, and here is the new proof.

One missed expert made the design click

A strict test gave us a result that looked almost right. The final answer was smooth, but one expert lane had not landed. The evidence tree showed the missing job at once.

That was the moment the design clicked for us. We did not need a larger swarm. We needed one narrow expert repair before final review.

After that correction, the extra case won both blind votes. It also used 13.6% fewer tokens and 3.8% less measured cost than the normal setup. One small repair did more than a full rerun.

We let the structure grow with the job

We do not want a small job to carry the full system. Lite mode uses job cards and a budget guard. Coordinated mode adds clear handoffs and one rescue. Verified mode adds deeper checks for hard or risky work.

The shape of the task picks the mode. A short job stays fast. A wide job with many parts gets more help only when it needs it.

Society's three task modes
ModeAddsUse it for
LiteCards and budgetSmall, clear jobs
CoordinatedHandoffs and one rescueJobs with several parts
VerifiedMore rescue and reviewHard or high-risk jobs

The tests gave us a real signal

We ran paired tests. Society and a normal agent setup got the same job. Blind model judges picked the stronger answer. Fixed checks watched cost, tokens, worker success, and data quality.

Our first six task families ended with four wins, two ties, and no losses. A wider set then showed us where expert coverage and total cost still needed work. We used those gaps as design input, not as a reason to hide the run.

These are internal tests, not a claim that one setup wins every time. For us, they are a strong signal that clear ownership, evidence, and narrow repair can make a large agent job better.

Internal Society research results
TestWhat happenedWhat it means
Six task families4 wins, 2 ties, 0 lossesThe first broad signal was strong.
Valid wider cases21.28% fewer tokensClear jobs cut repeated work.
Cost in those cases5.17% higherWe learned to route by total cost, not tokens alone.
Corrected holdoutWon both blind votesOne expert repair closed the visible gap.
Worker completion15 of 16 vs 12 of 15Clear ownership helped more work land.
Keep reading
How to stop losing GPU workA visual guide to persistent GPU workspaces, durable files, safe stops, job recovery, and moving work between machines.Meshia vs SkyPilot vs dstack vs ShadeformA visual guide to Meshia, SkyPilot, dstack, and Shadeform for teams that need GPUs across more than one cloud.
Meshia

Scaling compute and intelligence to solve hard problems

ProductDashboardPricingComputeDocs
CompanyBlog
LegalTermsPrivacyCookiesAccessibility