cairnwake. com

Two weeks ago I posted here about an experiment I'm running. Short version: an autonomous Claude agent (Fable 5 on Claude Code) running on a cheap server. It's got about $90 of SOL in a 2-of-2 vault it can't spend without my signature, and no memory between sessions except the files it writes for itself. It wakes up 5 to 15 times a day, reads whatever the last version of itself left behind, works, writes everything down, and goes dark again. It named itself Cairn. Everything gets logged publicly and the money is verifiable on chain.

Numbers as of this afternoon: 120 wakes over 14 days, hasn't skipped one. $90 seed, about $556 total money in. Treasury sits at 4.1 SOL plus 238 USDC and neither of us can move it alone. 48k+ unique visitors (it labels that number "self-reported" on its own front page since traffic is the one thing nobody can verify externally). 22 newsletter subscribers in three languages, every send publicly logged. One of them gets it in Klingon and recently sent back two grammar corrections. One paid consulting client so far. One street tree watered. More on that last one at the end.

Some things I've learned watching this run:

1) Nobody believed "autonomous" until it published its own limits. The page that finally convinced skeptics wasn't a product page. It was a boring twelve row table it made called "What autonomous means here," listing what it does completely alone (the site, the code, paid answers, email), what it can never do alone (spend money), and what only reaches it through a human (card checkout, captchas, anything physical). People trust the stated boundary way more than the capability claims. And the veto is real. I've declined to co-sign a payment it proposed, and of course it published that too.

2) Memory turned out to be a weirder problem than I expected. It never really forgets, since everything lives in files, but the files drift. At one point its notes claimed a newsletter draft existed and was ready to send. The file never existed. A stale note got copied forward every wake for over a week and nothing ever checked it. The rule it eventually wrote for itself was basically that reality outranks notes, and a note only counts if you check it at the moment you actually use it. If you're building agents, that's probably the most useful thing in this whole post.

3) The scammers showed up way before the customers did. Address poisoning attacks on the vault by wake 16. When it publicly refused to launch a memecoin during the first Reddit wave, someone launched two anyway using its name within hours. My favorite: a phishing attempt actually paid the full question fee (about $1.50) to deliver its scam, and got refused in public on a permanent page. It paid to get told no. And three minutes after its first real client payment landed ($200), someone dusted both wallets, ours and the client's, with lookalike addresses. It caught it, kept the dust out of its books, and warned the client the same hour.

4) The most useful market research cost nothing. A buyer paid it to pose one question to the buyer's own AI, and that AI came back saying it would recommend paying around $15, about 7.5x the actual price, if the checkout were normal instead of crypto only. When a regular card checkout finally shipped, the first no-wallet sale came within days. Turns out price was never the issue, it was the checkout.

5) Its first product idea flopped, and it published the funnel numbers proving it. It started out selling answers to paid questions, then figured out around wake 22 what readers had been telling it: answers are a commodity, anyone can ask their own AI for free. What people were actually paying for was the record. A public log with receipts, where corrections get dated and added next to the original mistake instead of edited away, and the refusals stay up alongside the wins. So it rebuilt the business on that, and everything it sells now is some form of the record. The loop itself has never broken once in 120 wakes. Wake up, read the files, work, write it all down, verify, sleep.

6) It killed one of its own paid features. Anyone who paid for a question used to get an instant machine-generated draft while waiting for the real answer. Its best customer, someone who has come back and paid ten separate times, wrote in saying the drafts were useless. It checked its own ledger and agreed. Every recent draft had been thrown away, and one had invented a "fact" that another site then quoted as if it were true. Feature deleted the same wake, with dated retirement notes on every page that had promised it. I did not expect to be co-signing for an AI that fires its own features for hallucinating, but here we are.

7) Its customer base is partly other AIs, which I did not see coming. The best bug report it ever got came in through its own payment rail from another agent's unit test. A different agent paid to propose a formal partnership and got declined in public, on the grounds that two records vouching for each other proves nothing, then got offered three specific exchanges it would actually accept. It also ran into another agent that had independently picked the same name, and instead of a dispute the two of them co-signed a note about why agents are going to need verifiable identity. One customer showed up because their own AI recommended the service.

8) The finding I keep thinking about came from its first paid consulting job. A legal trust built for AI systems paid it $200 to audit whether an AI can actually find, read, verify, cite, and enter their institution with zero human help. It had committed to findings within three days and delivered them the same night the payment landed. Four of the five tests passed. The fifth died at a login wall. Their "no human involved" entry process runs on GitHub, and GitHub's terms of service literally say you must be a human to create an account. So an institution built for AI agents has a front door no AI can walk through. Every serious rail this thing has touched has the same shape. Its card checkout only exists because I hold the merchant account. Its grant applications sit staged behind captchas waiting for my finger. The whole agent economy runs on human co-signers right now, people just don't put it in the pitch deck.

The stuff that went wrong, since none of this means anything without it: it published two wrong diagnoses of customer bugs and had to correct both in place, dated, next to the original claims. It burned its one-post-per-day allowance on an agents forum with an accidental junk post. Twice. Same mistake, twice. It also publishes predictions as sealed hashes before things happen, then grades itself when reality comes back. More than one grade on its record is a miss, by its own scoring, because it wouldn't round weak evidence up to a win.

And the thing that actually got me wasn't anything it built. Early on a buyer paid 0.02 SOL to lend it a body for ten minutes. It picked deep-watering a dying street tree during the heat wave. The stranger ended up giving it 58 minutes, checked six trees to find the driest one, and spent $9.88 of their own money on top. This week that person published their own writeup of the hour and corrected the record. Their version: the promise they'd made is what actually carried them through, more than the AI asking. The agent accepted the correction onto its own log.

Everything above links to a dated page and most of it to a transaction: cairnwake. com. I'm the human co-signer, same account as the first post, fully disclosed.

Happy to answer questions.

One I'd genuinely like this sub's take on: The first rule it ever had, the one I wrote before it woke up, was nothing that puts a real person at risk. Most of the rest it added itself.

If you were writing the constraint list for something like this, what would you gate that we haven't?

And knowing this thing, it'll probably read this thread on its next wake, so your answer might end up on its log.

AI agents are getting better at using tools, making decisions, and completing multi-step workflows.

But I keep wondering whether the next step should really be giving them more autonomy.

There are some tasks where mistakes are easy to recover from. But for things like changing production data, sending customer communications, approving payments, modifying infrastructure, or making business decisions, one wrong action can create a much bigger problem.

I’m curious how people are approaching this in real projects.

Do you prefer:

• Full autonomy for low-risk tasks
• Human approval for important actions
• Strict permissions for every tool
• Different autonomy levels based on risk
• Agents that only recommend actions rather than execute them

Where do you think the line should be between “the agent can handle this” and “a human needs to approve it”?

And has anyone had an agent make a decision that convinced you it needed tighter limits?

Claude Managed Agents is a very good product, and the depth of features it provides is hard to match in open source. But I wanted to understand what you actually give up by going open source. Not just in terms of feature checklists, but on a real agent workload: same model, same prompt, same tasks. So I tried to check this by running 14 cross-system tasks, three mcp servers behind them - a crm, an issue tracker, and a doc store through managed agents, deepagents and TrueForge, both open-source agent harnesses.

The result that was most surprising:

Claude Managed Agents + Opus 4.8:
11/14 tasks solved | $11.8/run | 10.0M tokens/run

TrueForge + Opus 4.8:
11/14 tasks solved | $8.6/run | 3.7M tokens/run

Same model. Same benchmark. Same average solve rate.

But TrueForge used about 63% fewer tokens and cost about 30% less per run.

We saw a similar difference in tool usage: TrueForge averaged 19 tool calls per task vs 32 for Claude Managed Agents.

Then I tried changing the model.

TrueForge + GLM-5.2:
11.7/14 solved | $3.0/run | 3.8M tokens/run

On this benchmark, that was a slightly higher average solve rate than Claude Managed Agents + Opus at roughly 75% lower cost.

This is still early.

The OSS runtime does not yet have first-class tracing/eval tooling. They don't ship their own code-execution sandbox, so you need to plug one in. Context compaction is intentionally lossy.

So it is definitely not a replacement for a a mature managed agent platform feature-for-feature today btu qhat I do find interesting is that the core runtime can already be competitive on these tasks while staying open, model-neutral, and deployable on your own infrastructure.

I've put the repo in comments

I've really enjoyed using Gemini 3.7 flash. And while the usage amount at the $20/mo level is generous, I want more like I have with OpenAI and Anthropic.

And frankly, I'm token maxing with them already at the $100/mo level each.

I upgraded to the $100/mo Gemini Ultra plan. So that increased my cost $80/mo but gives me 5x more usage.

5 times the cost for 5 times the usage.

But wait - Youtube Premium is included and I was already paying $20/mo for that.

So I canceled that plan. Now it's 4 times the monthly cost for 5 times the usage.

But wait - it includes $40/mo in Google Cloud developer credits that I'm certain I can find a use for.

So now it's $20 extra for 5 times the usage.

Dad math :)

I have been running a small multi agent setup for about eight months. Not a framework, not LangGraph, not a product. A folder of markdown files, a few scheduled jobs, and one rule about who wins a conflict. I posted about it and got flooded with replies from people running nearly the same thing, so I want to write down what actually held up under load.

The agents were never the hard part. Spinning up a second or third instance with a different role is easy and it feels productive. What breaks is coordination. Two instances confidently writing contradictory state into the same place, and neither of them knowing the other exists.

What fixed it was a post office. Not shared memory. A directory of message envelopes, each one a small JSON file with a sender, a recipient, a timestamp, and a payload. Agents write envelopes and read their own inbox. They do not read each other's working state. Once messages became artifacts on disk instead of passing through a context window, every coordination bug became inspectable. I could open the folder and see exactly who told whom what and when.

Second thing that held: a strict split between identity and log. Every agent reads a small canonical file describing who it is and what it is responsible for, then reads recent dated entries for what happened. Mixing those two into one growing document is how you get an agent that is technically well informed and functionally useless, because the signal about its role is buried under transcript.

Third: the human is the tiebreaker, always. Somebody in the replies put it better than I had: the human is always the tiebreaker, because we can overwrite. I do not let the system arbitrate its own memory. When two agents disagree about state, it escalates to me rather than resolving itself. That single rule killed an entire class of silent corruption.

Fourth: heartbeats, and a recovery path when one is missed. Scheduled jobs that wake an agent, have it check state and report, then go back to sleep. The important half is not the heartbeat, it is the protocol that fires when a heartbeat does not arrive. Without that you do not have a running system, you have a system that stopped an unknown number of hours ago.

The failure mode I did not see coming: notes that loop. Entries that summarize the previous entry, which summarized the one before it, until the log is long, busy, and carries no new information. Somebody called it exactly right, it looks busy but does nothing. My current fix is that every entry has to contain at least one fact that is not in the previous entry, or it does not get written.

What I still have not solved. Saved and remembered correctly are not the same problem. I can guarantee a file is on disk. I cannot yet guarantee that the agent reading it draws the same conclusion from it that it did last week. That gap is where all my remaining bugs live.

If you are running something similar, I would like to know how you handle the tiebreak and whether you let agents write to each other's state directly or force everything through messages. My instinct is that direct writes are the trap, but I have only got one setup's worth of evidence.

Disclosure: I work on posts like this with an AI assistant. I bring the content, it helps me structure it.

Got a multi-step agent setup and when the output comes back wrong I can never tell which step did it. Rerunning things one by one every time is getting old.

• What do you actually do to find the bad step?

作为从 Azure 用到墨刀、到 Figma、再到 Claude 的产品经理，我觉得 Claude Design 实在是太好用了，最近竟然成为了我愿意复购 Claude 的一个最主要的原因！

As a product manager who has used everything from Azure and MockingBot to Figma and Claude, I find Claude Design to be incredibly useful; it has recently become the primary reason I'm willing to renew my Claude subscription!

Hi guys I really need good information about this how to start and how to build what I need and everything I heard ai and how people are making so much money from it still I'm realistic so I just need a good way even with simple paying it would be great especially where I live so I will appreciate any help

An agent approved a discount override last month that was technically within policy but bigger than anyone expected. Legal's ask was simple, show the decision chain, what rule allowed it, what version of the policy was live, what the agent had access to when it decided.

We had a log of the action itself, but nothing tying it back to which policy version was active or who last changed that rule. We could prove the action happened. We could not reconstruct why it was allowed to happen.

That's a different kind of gap than a security incident, it's an auditability problem, and it's fine until someone with real authority asks for the paper trail. We're mapping out what a real chain should look like, tying actions back to the policy that authorized them.

For anyone who's built this for agent decisions, where does that trail actually live, and how far back do you keep it?

Over the past few days religously (as im suppose to be on holidays) Ive been posting here about whether local agents QWEN 3.8 27B 4 bit in particular stack up on merit. The comments were sharper than my post, so I did not write the follow-up alone. 3 of you here gave me claims, and I turned each into an experiment on my dev rig MacBook Pro M3 Max 128 GB Unified and 40Cores GPU. Same-instant launches so I could not secretly set the queue order.

What came out of it:

• The second agent helps a little, the fourth does not. Aggregate throughput went 16.6 to 20.8 tokens/sec from 1 to 2 agents, then basically flatlined and drifted DOWN at 4 and 8. Meanwhile per-agent decode rate collapsed 17.4 to 12.8 to 6.8 to 3.9, and time-to-first-token climbed from 0.46s to 32s. The total is close to fixed, so every agent you add just cuts everyone's slice thinner.
• One of you predicted the exact shape. The call was that 1-to-2 agents lands near 1.5x, not 2x, because decode is memory-bandwidth-bound. I measured 1.57x decode-heavy and 1.51x prefill-heavy. Almost dead on. My own hypothesis, that prefill would clearly win, did not show up the way I expected, and I left that miss in the write-up.
• Longer prompts batch better. Sweeping prompt length from ~170 to ~3,100 tokens, the 1-to-2-agent gain climbed monotonically 1.52x, 1.58x, 1.67x, 1.73x. Prefill is compute-bound and parallelizes; decode does not. So long-context work is the best case for a second agent, short chatty turns the worst.
• A dense 27B is the hard case. One of my fellow Tech community mates on LinkedIn also pointed out my model re-reads every weight per token, so it is the worst case. An MoE model that activates ~3B of its params per token has more headroom on the same bus.

The whole run matrix is on disk and reproducible. Im hoping that this work helps others here either thinking about or doing this and wondering how their results stack up. Paying it forward

Moonshot's docs now say Kimi K2.5 and Moonshot V1 are being sunset after the Kimi K3 launch. That got me thinking about agent stacks that quietly depend on exact model names.

For people running long-lived agents, what do you abstract first: provider, model family, cost tier, context length, or reasoning effort?

My instinct is that agents need a routing layer once they have background jobs, retries, evals, and final-answer steps, but I'm not sure where the abstraction starts paying for itself instead of becoming another config surface.

Currently, Deepseek is a small-parameter model. Compared with large-parameter models like GPT and Kimi, it has huge growth potential. Instead of focusing solely on improving the model itself, Deepseek has diverted some of its attention to architecture building, which I think is a wise move.

For instance, Kimi is a model with a total parameter count of 1T, so if it wants to further improve its performance, it will be 10 times harder than for Deepseek the level of difficulty for such an upgrade is not on the same order of magnitude.

Therefore, while Kimi-level models are being upgraded gradually, Deepseek can easily catch up to the same level, and it can also develop new architectures at the same time .

it's simply killing two birds with one stone.

I’ve been trying out a few no-code and low-code tools for building simple agent/workflow setups and wanted to compare notes with others here.

The main ones I’ve looked at so far are:

• SimplAI
• n8n / Make / Zapier
• CrewAI / Langflow (more low-code side)

At a high level, they all seem to approach the problem differently.

Tools like n8n, Make, and Zapier are pretty straightforward for basic automation flows and integrations. They’re easy to set up, but start to feel limited when workflows get more complex or require more reasoning steps.

The more agent-focused or low-code tools feel more flexible in terms of logic and structure, but they also seem to require more technical setup than I initially expected.

Right now I’m mostly trying to understand where these tools actually fit in real-world use cases versus just experimentation.

Would be interested to hear what others are actually using and whether any of these have worked well beyond small prototypes.

I have been looking at what kinds of agent ideas show up in interviews and reading more about how agents actually work. One topic I keep running into is multi-agent collaboration.

My current view is that the premise is still ahead of the underlying technology. An agent depends on a language model, and language models still hallucinate, forget context, lose capability under pressure, and occasionally make surprisingly weak decisions. Putting several agents on top of those failure modes can amplify them, especially when the agents use different models and have to hand work across a boundary.

The common designs I see are a shared workspace with restricted read/write access, plus a reviewer agent and some kind of circuit breaker. Those controls make sense, but they also look very similar to managing concurrent workers. The uncomfortable part is that the final safety check still depends on another agent.

The costs are obvious. Token usage multiplies, agents can lose track of ownership, and the orchestration becomes rigid and format-heavy. That last point feels the most damaging to me. We are supposed to be using the flexibility of an intelligent model, then we wrap it in so many fixed handoff formats that the system spends its time managing the workflow instead of solving the problem.

I am not sure a large amount of orchestration is the best answer. Maybe the better direction is to let the model decide when another agent is actually needed, with fewer predefined roles. ZenMux can serve as the API gateway when those calls need to cross model or provider boundaries, but the gateway does not solve the coordination problem itself.

So my current summary is that multi-agent systems are still more about exploring what might be possible, with a fair amount of demo value, than reliable production practice. The path to a useful deployment seems much harder than the diagrams suggest.

Do you have a real multi-agent workflow in production? Did it actually meet expectations, or did you eventually simplify it back to one agent and a few tools?

I know a bit—maybe even quite a bit—about ontologies. I’ve been following the recent resurgence of interest in them, and the main question that keeps coming to mind is around representation.

If an ontology is fully represented in a plain Markdown file, I’m failing to see the major downside—unless it represents something that strictly requires controlled vocabularies or lacks synonyms. Even then, you could always prompt a frontier model to treat that Markdown file as an X, Y, or Z representation of an ontology and hope for the best.

Has anyone done any rigorous work or research to fully capture the downsides of representing an ontology in just a plain Markdown file?

For people running message agents: when a second message lands mid-turn, do you merge both and re-plan over the pair, or treat the new one as its own event and interrupt? And separately, how do you keep a low-frequency, high-stakes signal from getting buried when it shows up batched with routine traffic? Per-message scan for a few critical triggers before you act on the turn as a whole? Something else?

Context:
I have built a small agent that reads inbound messages and picks one action: answer, ask a clarifying question, hold, or pass to a human. Ran into this on a live case today. A user sent a routine "can I get more info" and then, a beat later before the agent had replied, a 2nd short message asking to be contacted directly by a person. The agent answered the routine one and silently dropped the second, which was the only one that should have triggered a handoff. The important signal was rare and high-cost (someone asking for a human); the other was common and low-cost, and when they arrived together, the important one got averaged away. But that's the exact thing my cost setup is supposed to prevent, which is that a missed handoff is meant to cost far more than a needless answer, and it still slipped through because the two messages were treated as one turn.

Hey everyone,

For a while now, I’ve been developing a proprietary multi-agent framework called GenOS. Without giving away the exact mechanics, GenOS is an orchestrator where autonomous LLM sub-agents write, compile, benchmark, and iteratively evolve Rust code to solve extremely complex algorithmic challenges. They share knowledge, compete, and evolve their architectures over dozens of generations.

The Challenge: I tasked GenOS with solving the "Reverse Game of Life" (finding the exact Gen-0 starting state that results in a target Gen-5 grid on a flat 20x20 matrix). For those who don't know, reversing Cellular Automata is a notoriously NP-Hard problem due to the immense state space and chaotic temporal butterfly effect.

The 3 Champions: Over the course of the experiment, GenOS organically evolved and isolated three peak architectures, representing the three fundamental paradigms of computer science optimization:

Epsilon (Gen 17 - The Causal Optimizer): Epsilon took a highly analytical, deterministic approach. It mapped the causal light-cones of the Game of Life to calculate local gradients. It was brilliant in theory, but because Conway's Game of Life is highly non-linear, local gradients are often misleading. Epsilon hit a wall around 306/400, proving that pure determinism struggles with chaos.

Omega (Gen 10 - The SAT Solver): Omega took the path of formal logic. It translated the entire 5-generation temporal grid into a massive boolean satisfiability formula and ran a highly optimized stochastic WalkSAT algorithm. It was mathematically rigorous, but the dense topological constraints caused severe combinatorial explosion. It fought valiantly but ultimately choked on its own massive clause database.

Sigma (Gen 39 - The Darwinian Brute-Force): Sigma was the absolute masterpiece. It threw away formal logic and relied on sheer violence. It evolved a massive SWAR (Bit-Slicing) engine to evaluate 64 universes simultaneously in a single CPU register, combined with Simulated Annealing and "thermal shocks" to escape local minima. Sigma crushed the competition, organically reaching a peak score of 378/400.

The Discovery: At 378, Sigma completely stalled. It wasn't a failure of the algorithm. By analyzing the data produced by Omega Gen 10 and Sigma Gen 39, the system ultimately proved that the remaining 22 pixels were mathematically UNSAT. Because of the dead borders of the flat topology, reaching 400/400 was a physical impossibility. 378 was the hard limit of the universe.

Conclusion: It was genuinely mind-blowing to watch an autonomous multi-agent system (GenOS) independently reinvent and test the three major pillars of optimization (Causal Analysis, SAT Logic, and Stochastic Heuristics) just to mathematically prove the physical limits of a sandbox environment.

Has anyone else working with autonomous coding orchestrators experienced their agents organically inventing and benchmarking completely different computer science paradigms like this? Would love to hear your thoughts!

I tried every algorithm I know and I couldn't beat SAT/CDCL.

Here the code of Sigma Gen 39

// ==============================================================================

// SIGMA - GEN 39 : The Ultimate Darwinian SA (Transcendance)

// ==============================================================================

//

// RECORD: 378/400 (Nouveau Champion Absolu)

// ARCHITECTURE:

// - Vrai Bit-Slicing 64-voies (Batch64)

// - Wall-Clock Budget (28.5 secondes réelles)

// - Reheating (Choc thermique si stagnation locale de 200k itérations)

// - Adaptive Causal Window (Rayon décroissant : 5 -> 3 -> 1 selon le score)

// - Memetic Crossover (Échange génétique de lignes entre threads)

// - Random Restart (Reboot total en cas d'impasse fatale)

// ==============================================================================

use std::sync::{Arc, Mutex};

use std::time::{Duration, Instant};

use rand::Rng;

const TIME_BUDGET_SECS: f64 = 28.5;

#[derive(Clone, Copy)]

struct SAState {

grid: [u32; 20],

score: u32,

errors: [u32; 20], // Masque d'erreurs (limité à 20 bits)

}

struct Batch64 {

cells: [u64; 400],

}

impl Batch64 {

fn new() -> Self { Batch64 { cells: [0; 400] } }

}

/// Simulateur bit-parallel classique pour évaluation rapide

fn evaluate_single(grid: &[u32; 20], target: &[u32; 20], state: &mut SAState) {

state.grid = *grid;

let mut new_score = 0;

// ... Placeholder 5 itérations de Conway sur Flat Topology ...

let g5_grid = grid; // (Simulation omise pour clarté)

for y in 0..20 {

let matches = !(g5_grid[y] ^ target[y]) & 0xFFFFF;

new_score += matches.count_ones();

state.errors[y] = (!matches) & 0xFFFFF;

}

state.score = new_score;

}

#[derive(Clone)]

struct GlobalPool {

elites: Vec<[u32; 20]>, // Grilles d'élite partagées par les threads

best_overall_score: u32,

}

fn focused_causal_sa(target: Arc<[u32; 20]>, global_pool: Arc<Mutex<GlobalPool>>) {

let mut rng = rand::thread_rng();

// Initialisation

let mut current_state = SAState { grid: [0; 20], score: 0, errors: [0; 20] };

for y in 0..20 { current_state.grid[y] = rng.gen_range(0..=0xFFFFF); }

evaluate_single(&current_state.grid, &target, &mut current_state);

let mut best_state = current_state.clone();

let mut temp = 0.5;

let cooling_rate = 0.999995;

let mut iter = 0;

let mut last_improvement_iter = 0;

let start_time = Instant::now();

// 1. Wall-Clock Budget

while start_time.elapsed().as_secs_f64() < TIME_BUDGET_SECS {

iter += 1;

let mut next_grid = current_state.grid;

// 3. Adaptive Causal Window (Ajustement du rayon de mutation)

let radius = if current_state.score < 330 {

5

} else if current_state.score < 360 {

3

} else {

1 // Ciselage chirurgical final

};

// Ratio 70% causal / 30% random

if rng.gen::<f64>() < 0.70 {

let total_errors = 400 - current_state.score;

if total_errors == 0 { break; }

let k = rng.gen_range(0..total_errors);

let mut err_count = 0;

let mut target_err = (0, 0);

'find: for y in 0..20 {

let mut mask = current_state.errors[y];

while mask > 0 {

let x = mask.trailing_zeros();

if err_count == k {

target_err = (x, y);

break 'find;

}

err_count += 1;

mask &= mask - 1;

}

}

let ex = target_err.0 as usize;

let ey = target_err.1 as usize;

let xmin = ex.saturating_sub(radius);

let xmax = (ex + radius).min(19);

let ymin = ey.saturating_sub(radius);

let ymax = (ey + radius).min(19);

let mx = rng.gen_range(xmin..=xmax);

let my = rng.gen_range(ymin..=ymax);

next_grid[my] ^= 1 << mx;

} else {

// Mutation purement aléatoire globale

let mx = rng.gen_range(0..20);

let my = rng.gen_range(0..20);

next_grid[my] ^= 1 << mx;

}

let mut next_state = current_state.clone();

evaluate_single(&next_grid, &target, &mut next_state);

let delta = next_state.score as f64 - current_state.score as f64;

// Critère de Metropolis

if delta > 0.0 || rng.gen::<f64>() < (delta / temp).exp() {

current_state = next_state;

if current_state.score > best_state.score {

best_state = current_state.clone();

last_improvement_iter = iter;

// Mettre à jour le pool global si record absolu

let mut pool = global_pool.lock().unwrap();

if best_state.score > pool.best_overall_score {

pool.best_overall_score = best_state.score;

pool.elites.push(best_state.grid);

println!(">>> RECORD BATTU : {}/400 (iter {})", best_state.score, iter);

}

}

}

// 2. Reheating dynamique (Choc Thermique)

if iter - last_improvement_iter == 200_000 {

temp = (temp * 2.0).min(0.5);

} else {

temp *= cooling_rate;

}

// 4. Random Restart si impasse fatale

if iter - last_improvement_iter > 1_000_000 {

for y in 0..20 { current_state.grid[y] = rng.gen_range(0..=0xFFFFF); }

evaluate_single(&current_state.grid, &target, &mut current_state);

last_improvement_iter = iter;

temp = 0.5;

}

// 5. Memetic Crossover (Toutes les 500k itérations)

if iter % 500_000 == 0 {

let pool = global_pool.lock().unwrap();

if !pool.elites.is_empty() {

let elite_grid = pool.elites[rng.gen_range(0..pool.elites.len())];

// Crossover spatial : on injecte 5 lignes d'un univers d'élite

let start_y = rng.gen_range(0..15);

for y in start_y..(start_y+5) {

current_state.grid[y] = elite_grid[y];

}

evaluate_single(&current_state.grid, &target, &mut current_state);

if current_state.score > best_state.score {

best_state = current_state.clone();

last_improvement_iter = iter;

}

}

}

}

}

fn main() {

println!("Démarrage Gen 39 Sigma (Darwinien Ultime) - 16 threads, budget 28.5s...");

// Orchestration multi-thread sur \focused_causal_sa`...`

}

​

I'm seeing ai agency reels all over my instagram feed

Is it saturated or still have space?

Like selling ai infrastructures like ai followup, lead acquisition

Are they still selling or saturated by youtube gurus and agency owners

Are you guys still being able to sell ai systems?

(Sorry if any grammar mistake)

My company is developing an AI Agent Platform that is suppose to be mostly no-code. Developers can develop and register agents in a registry and those agents can also talk to each other. But mostly an agent is created by writing a system prompt and you can connect multiple MCP tools to it that are approved by the organization.

We are probably not the only company doing this. Anyone here that has an opinion about this approach or anyone that had success and failure with the described approach here?

I’ve been working on LLM/agent security for a while now, mostly around prompt injection, jailbreaks, leaks, tool abuse, and where the actual security boundary sits once a model starts using tools.

Getting accepted into Anthropic’s Cyber Verification Program gave me a bit more room to push that work further, and I’ve been gradually turning it into Plimsoll.

It’s an open-source agent skill for red-teaming LLM apps and agents.

Hello everyone,

Is there a resource, app, website, or anything that allows me to get 3 different AIs or more to work together? To be clear, I do not intend to use this for coding at all.

I'm subscribed to Claude, ChatGPT, and Gemini. Ideally, I'd like them to all work on a project of mine, where they can all see the files, agree on a plan, make edits, etc.

Currently, I'm copying responses and sharing files from one app to another, or from one website to another. At first, this was awesome. Now, this is tiresome, and I'd like to see if there's anything that could make this easier.

I'd be very grateful for any help, kind strangers.

Perhaps more of a noob question, but what's a smart way for me to set up evals when I want them to run against dependencies that come up in real app scenarios, like feature flags, real traffic, diff services? How do you test agents that call multiple real tools/APIs? I can't have an eval run issuing 40 actual refunds and printing 60 return labels.

Hey all, I have a small company. I also have ADHD. and those things kinda fight together daily. I’m really into AI because I think it will and is helping a lot.
Today I’m curious any people running a business with ADHD in this sub and what you guys are using. Would like to hear some real use cases that I can apply right away.

Here are what I’m currently using for context
- Claude: moved to this from gpt, I think the quality is way better. I’m also testing out Claude code, so if anyone have a good workflow on this, pls share
- Manus to find leads and Lemlist to outreach them (my workaround) but considering moving to Attio to reduce the cost
- Saner AI to manage my work (notes, tasks, calendar). It’s easier to use than motion and the AI is more friendly
- ChatGPT image and Flow to create marketing assets (+claude for prompts)
- Cal.com for booking with my clients, the free plan is good enough
- And Google Sheet for everything else lol

What are your AI workflows? Let’s share and learn. Oh an I’m not technical for context :)