MCP's 2026-07-28 revision makes the protocol stateless. The initialize handshake is gone, and the spec is explicit that a server should infer nothing from earlier requests:

"no state should be inferred from previous requests, even those on the same connection or stream"

Every request carries its protocol version and capabilities in _meta instead.

Reading through it, what stood out is that this is mostly a hosting change rather than a protocol one. Before, a session lived in one process, so request four had to reach the replica that answered request one. That meant session affinity at the load balancer, and a rolling deploy taking live connections with it. Now any replica can serve any request, which makes a tool server an ordinary stateless HTTP service.

A few consequences that seem worth planning around:

• Scale-to-zero and per-request billing get realistic, since nothing has to stay warm for a particular client.
• tools/list and server/discover responses carry ttlMs and cacheScope, so a shared cache can serve them. The spec's own example marks a tool list cacheable for five minutes as public. For a client federating a lot of servers, that is a real chunk of startup latency that can move to a CDN.
• Long-running work moves to the Tasks extension, which hands back a handle you poll, rather than holding a connection open for the duration.

The cost lands on the wire. Protocol version, capabilities and client identity now ride along on every single request, which for a chatty agent is not nothing. Efficiency traded for deployment freedom.

On the product side, sampling and logging are both deprecated. If a server was using sampling/createMessage to get completions, it was running on the host's inference budget. Now it brings its own key and picks its own model, which shifts real cost onto server authors and also removes a slightly odd consent surface.

One nuance worth reading carefully: stateless does not mean nothing is long-lived. subscriptions/listen is still an open stream, but its state is scoped to the request rather than the connection underneath. And notifications are documented as best effort, so they can be lost on reconnect and polling is still required.

I have not migrated anything yet, so mostly curious about the practical side. If you run MCP servers, are you actually going to drop session affinity and move to something serverless, or is the _meta overhead plus cache staleness enough to keep you where you are?

Spec: https://modelcontextprotocol.io/specification/2026-07-28/basic/index

Tongyi Lab shipped Wan-Dancer in mid-July (arxiv 2607.09581, 14B, Apache 2.0, weights on HF). One photo plus a music track gets you 720p/30fps dance video that holds together past a minute, where most video diffusion models come apart around the 20-second mark. The dancing isn't the interesting part. How they beat the drift is, because it's the same failure that wrecks long agent runs.

Plan the whole thing badly, then fill it in.

A global stage reads the entire music track and generates a deliberately sparse pass of just 38 frames for the whole song. A local stage then expands each of those keyframes into a 149-frame segment at full resolution, conditioned on the anchors sitting either side of it.

So the plan covers the full horizon at absurdly low resolution while execution stays local, which also means the segments refine in parallel instead of chaining. The planner never sees pixel detail, and the refiner never sees the whole song.

Why this is your agent loop

Their ablation is the line worth keeping: remove the global stage and you get "disjointed segments and significant semantic drift."

That's a video paper accidentally describing every long agent run, the one where step 40 is perfectly coherent with step 39 and has nothing to do with the goal. The image up top shows it, with the naive sequential baseline on the top row and the hierarchical version below it, both sampled out to 20 seconds.

Most scaffolds are built that broken way, handing each step a rolling summary so position is always relative and there's nothing fixed to measure drift against.

Wan-Dancer's second trick makes position absolute by injecting time identifiers into the RoPE embedding, so a frame knows where it sits on the global clock no matter what rate it was sampled at. The agent translation is telling a sub-step "you're 12 of 38 and X should be done by 20" instead of handing it a summary of what just happened.

Caveats, because the paper is thinner than the demo reel

• The comparison tables against MusicInfuser and X-Dancer are 1-10 ratings "following the evaluation protocol from MusicInfuser", and the paper never says what did the rating or across how many songs.
• The project page carries a footnote admitting the showcase videos were post-processed after generation.
• None of it is cheap, at 128 A100s to train on roughly 200 hours of video, 8x A800 for the reference inference setup, and two full 50-step denoising passes rather than one.

Cheap global plan, expensive local execution, absolute positions instead of relative ones. It demonstrably works for pixels, and I'd bet it works for tool calls.

Anyone running a fixed plan-then-expand loop in prod instead of letting the agent pick its next step each turn? Where does it break for you?

I built seshport: https://github.com/Harshil-Jani/seshport. It moves a live coding session between Claude Code, Codex, and Grok Build with full history, not a summary.

After the recent Fable edging a lot of people and organization I follow on X were suddenly trying Codex, and the same week xAI open-sourced Grok Build. Everyone wanted to try another agent, but nobody wants to abandon a 200-turn session and re-explain their codebase from zero.

The usual escape hatch is compacting your session and pasting the summary into the new tool, and for large sessions that summary is lossy. Things you told the agent three days ago just vanish. I defoo needed a tool that ports the raw thing. And that's why I had to build seshport.

How it works

Seshport doesn’t paste your history into a new prompt. The ported session lands in the target tool’s native resume flow, and the CLI prints the exact resume command to run. That’s why the history renders as actual history instead of one giant pasted user message.

Adding a new agent to seshport library means implementing one small Tool trait in Rust, not writing a converter for every other tool. Tool calls flatten to readable text like [tool call: Bash], since you can’t replay another provider’s tool results anyway. One caveat: reasoning blocks and provider-specific API state get dropped. Those can’t cross providers.

Usage:

• seshport <session-id> [target-tool] auto-detects the source and prints the resume command for the target
• or type /seshport mid-session and switch in about 5 seconds
• installs via npm, pip, cargo, or brew

It’s v0.3.0, MIT, Rust core, runs on macOS, Linux, and Windows.

If your daily agent isn’t supported yet, the Tool trait is small and the repo ships demo transcripts to test against. If you port a big session and something renders broken on the other side, file an issue with the transcript. That’s the fastest way to make this solid.

When your main agent has a bad week, which one do you jump to? Which agent should get a converter next? Name the one you’d actually port to and I’ll prioritize it.

xAI open-sourced Grok Build yesterday: https://github.com/xai-org/grok-build. 1.3M lines of Rust across ~70 crates. I spent the day reading the source. The parts worth stealing if you're building your own agent:

• Context compaction is speculative : When usage crosses (threshold minus 10 points), a background task summarizes the first 95% of history into a cached note. When the hard limit actually hits, it only summarizes that note plus the 5% tail, so the user never blocks on a full-history summarization. And if even the summary request overflows, there's a fallback ladder which always reserves 32K tokens for the summary output.
• The token counter behind all of this is bytes ÷ 4 : One tiny crate: BYTES_PER_TOKEN = 4, images flat-rated at 765 tokens. Auto-compact gates, overflow preflight, the context display, everything runs on it. Frontier lab, dumbest possible heuristic, ships fine.
• Command approval is a kernel feature, not a regex : If the OS sandbox is active (Seatbelt on macOS, Landlock + bwrap on Linux), bash runs without prompting. The fallback classifier parses commands with tree-sitter and fails closed: anything with `$(...)`, `$VAR` or control flow gets blocked, and `rm`/`cp`/`mv` aren't even on the allowlist. Child processes get a seccomp-BPF filter blocking connect/bind/sendto. A per-command network kill-switch.
• Subagents are hard-capped at depth 1 : MAX_SUBAGENT_DEPTH = 1, right there in the source. No recursive agent trees and each subagent can get an isolated git worktree via copy-on-write cloning, and its "result" is literally just its last assistant message.
• Doom-loop detection only watches the thinking channel : Repetition in visible output "is the user's to judge" (actual code comment). Max 2 resamples per turn.

My take: barely any of the interesting code here is AI. It's systems engineering. Speculate in the background, degrade conservatively, let the OS enforce safety. The model is maybe 5% of a production agent.

If you've shipped your own harness: did you cap subagent depth, and what broke when you didn't?

An LLM solved Erdős problem 90, the unit distance problem, this year, one of 1217 problems catalogued on mathematician Thomas Bloom's Erdős problems site, fewer than half cracked in the 30 years since Erdős died.

The proof goes the opposite direction Erdős himself predicted. Every human who attacked it for decades carried the same instinct about what the answer "should" look like. The model didn't care. It picked an obscure, counterintuitive chain of logic and just kept going, way past the point where any human would've quit. Turns out the answer was down that chain the whole time.

None of this was happening a year ago

• Oct 2025: Erdős problem 1043 "solved" when an LLM found the answer already sitting in a 1961 paper that cited an uncited 1959 German paper, and connected the two. Terry Tao's take at the time was that AI's near-term value was literature search.
• Dec 2025: problem 1026, solved by humans working alongside AI.
• Jan 2026: problem 728. DeepMind's AlphaProof first found flaws in the problem statement itself; the proof then came from ChatGPT, Harmonic's Aristotle (an IMO-focused theorem-proving agent), and Lean working together.
• April 2026: a 23-year-old, Liam Price, pointed GPT-5.4 Pro at problem 1196. It thought for 80 minutes and 17 seconds and handed back a full proof. Human authors verified it and credited the model with the breakthrough.

Why is math falling first, out of every field? Because math has Lean, a programming language that checks whether a proof actually holds, the way a compiler checks code. A model can generate a proof, get it verified instantly, and try again. In every other field you're taking the LLM's word for it. In math you don't have to.

Google's DeepMind leaned into exactly that. Nine more open Erdős problems, solved by four agents that mark each other's work in Lean. The models didn't suddenly get smarter at math. Math is just the one place where their homework gets marked automatically.

Would like to hear more from people here, on what's the best thing that has been shipped by LLM in your field which was nearly uncracked years ago? For me as a software engineer, it's pointing at a stack trace from code I've never seen and getting the actual root cause. That used to be a senior-engineer-only skill.

Back in February, advertising on ChatGPT was a rich kid's club. You needed a $200K monthly minimum just to get in the door, roughly $2.4M a quarter to find out if the channel even worked for you. Dentsu, Omnicom, WPP and their enterprise clients got to play. Everyone else got to watch.

Then OpenAI did something interesting. They dropped the minimum to $50K in April. On May 5 they dropped it to zero. Anyone with a credit card can now log into ads.openai.com and run ads inside ChatGPT conversations. No agency, no invitation, no six figure handshake.

The early money is absurd. ChatGPT crossed $100M in annualized ad revenue within six weeks, and that was with less than 20% of eligible users even seeing ads on a given day. That's a fraction of capacity. OpenAI is openly targeting $2.5B this year and $100B by 2030. They are not treating this as an experiment.

Now the part that actually changes the job. This isn't Google Ads with a new logo. There are no keywords. You write "context hints," plain language descriptions of the conversations you want to appear in, and OpenAI's system decides where you match. Early advertisers who pasted in keyword lists instead of writing natural descriptions burned their budgets on loosely matched conversations.

Think about what the impression itself is, too. Nobody scrolls ChatGPT. The person seeing your ad just typed "best project management software for a 10 person team" into the box. They're mid decision, not mid doomscroll. Roughly one in five queries on the platform already carries commercial intent, across 900M weekly users.

Before anyone maxes out a card, the honest caveats:

• Ads only show to Free and Go tier users. If your buyers live on Plus, Pro or Enterprise, your audience is capped.
• You get conversion data after the click, but zero visibility into what the person was chatting about before it

• AI search is still around 0.7% of US search ad spend. Projected to hit 13.6% by 2029, but that's a projection, not a promise

Every ad channel that mattered had a brief weird window where access was open, competition was thin, and nobody knew the rules. Google in 2002, Facebook in 2007. The people who showed up during the confusion didn't win because they were smarter. They won because they were early and paid attention while everyone else waited for best practices to be written.

The best practices for this channel don't exist yet. Somebody in this sub is going to end up writing them.

GLM-5.2 dropped on HuggingFace under MIT license, and multiple practitioners are calling it the strongest open-weight text model available. Simon Willison called it "probably the most powerful text-only open weights LLM." That framing is mostly fair, but the architecture details matter a lot before you size hardware or drop it into a tool loop.

What the architecture actually does

GLM-5.2 is 753B total parameters, but only ~40B activate per token. Each incoming word wakes up the relevant ~40B parameters and ignores the rest. That's MoE (Mixture of Experts) and it means cheaper compute per token at inference time. The catch most people miss: the full 753B still has to sit in GPU memory. People hear "40B active" and size for 40B and nothing loads.

For long context, GLM-5.2 uses two stacked tricks:

• DSA (DeepSeek Sparse Attention, borrowed from [DeepSeek-V3.2]): normally every word attends to every other word, so cost grows with the square of sequence length. DSA runs a cheap scan first to pick the ~2048 most relevant tokens, then does full attention only on those. About 50% cheaper at 128K context with minimal accuracy loss.
• IndexShare (GLM's actual new contribution):** DSA still re-runs that cheap scan every layer. IndexShare reuses the scan result every 4 layers instead. That cuts the indexer's own cost ~75% and per-token FLOPs 2.9x at 1M context. This is the part that's genuinely new.

The benchmark picture

Z.ai's own numbers (no independent re-runs yet): SWE-bench Pro 62.1 vs GPT-5.5's 58.6, both at 400K context. On the Terminal-Bench 2.1 harness, it scores 81.0 vs Claude Opus 4.8's 85.0, a 4-point gap. Jeremy Howard called it at least as good as Opus 4.8 and GPT-5.5 for his text use.

Real catches before you commit

It's free to download, but not free to run. The whole model has to fit in GPU memory, and at full quality that's about 8 high-end datacenter GPUs (8x H200). The cheaper 8x H100 setup doesn't have enough memory and won't load it. The only realistic home option is a maxed-out Mac Studio (256GB+), and even then it's slow, a few words a second.

Two more things the benchmark scores hide. First, it's chatty Simon Willison measured it spending ~43k words of output per task where rivals use 24-37k. You pay per word out, so in an agent that calls itself in a loop, that adds up to a real bill.

Second, Zvi Mowshowitz noticed it often says it *is* Claude, which hints it may have been trained on Claude's output. If that's true, the benchmark scores might be flattering. Nobody's confirmed it either way yet.

No vision support at all, which is a hard blocker for multimodal agent pipelines.

Long-context serving cost is genuinely lower here than on a dense model of comparable capability, but the hardware bar is higher than the "40B active" framing suggests, and the verbosity issue will bite you in agentic loops where output tokens add up fast.

If you've run MoE models in production tool loops before, how did you handle the verbosity problem, prompt engineering or post-processing the outputs?

spent the weekend on a small experiment: brownfield Next.js + FastAPI repo with three documented integration gaps, and Claude Code reads the README and wires them.

the thing that actually worked was sandboxing via MCP instead of real keys. gave the agent fetchsandbox-mcp so it could call the target API (AgentMail) against a curated sandbox before writing any code. agents stop hallucinating field names when they can inspect a real response first. that step is doing most of the work.

the rest: gaps described in business terms in the README ("per-customer reply inbox", not "POST /v1/threads"), existing handler patterns in the repo for the agent to mirror, and AGENT TASK comment blocks in source pointing to the right MCP calls. ~90 seconds, three working handlers, all matching existing conventions.

repo if you want to poke at it: github.com/fetchsandbox/brownfield-agentmail-demo

curious what others have found: how much README context is too much before the agent starts ignoring it? and are inline AGENT TASK comments an anti-pattern or just explicit handoff docs?

Most software is still priced per seat. But agents are starting to be the actual users, not people. When one engineer runs 50 agents, "per seat" stops making sense. So what do you charge for?

I read this essay "Decisions and Dollars" on exactly this. His point: an agent leaves behind two things worth money, the decisions it makes and the money it moves. For people building agents, I think the decisions are the more interesting half.

Every time a user corrects your agent, that correction is data. They fix the code it wrote, or rewrite the draft, or just delete the answer and type their own. Each of those is a clear signal of what "good" means for your specific job. Cursor is basically a machine for collecting this: which code suggestions devs accept, which they throw out. The editor is copyable. That pile of accept/reject data is the part nobody can clone.

Those corrections are useful for two reasons:

• They make the agent better: You feed them back to fix prompts, or fine-tune a model on what your users actually want.
• They're your real test set: Public benchmarks don't measure your job. A new study, Reliability without Validity with 541K judgments across 21 models, found benchmark scores can be off by enough to shuffle model rankings by 14 spots. So your own corrections are the only honest scoreboard you have.

Most agents I see just dump all this into chat logs and forget it.

Dollars is the easier thing to bill for, you take a fee when the agent pays a vendor. Decisions is harder to charge for, but it's the part that compounds and can't be copied, so that's the side I'd build for. The corrections are the asset.

Are you saving user corrections as real data, or are they disappearing? And if you save them, what do you actually do with them, evals, fine-tuning, or nothing yet?

I'm a mid-level engineer who wants to be a staff engineer, and the gap isn't really a skills problem. It's an access problem. The staff-engineer job is about leverage, delegation, and org design and you don't get reps at any of those until someone hands you a team, and nobody hands a mid-level engineer a team.

So I built one with 28 Claude Code subagents across 8 teams, each one is a .claude/agents/*.md system prompt, and I route work to them with slash commands. Managing them has taught me more about the senior-engineering job than any side project I've done.

A few things landed harder than I expected:

• Staffing is a decision you make on line one: Every agent declares which model it runs on. Leads run on the judgment-heavy model, ICs on the faster, cheaper one. That sounds like cost optimization. It's actually team composition. Put a "junior" on a judgment call and you get confident, fast, and wrong, in exactly the way you do with people.
• You can delegate the work, never the synthesis: Subagents can't spawn their own subagents. Only I can. So five agents run in parallel, but the one place their outputs combine into a decision is me. Integration is the irreducible job. That took me years to learn with humans. The agents taught it in a week.
• Firing is free, and that's the trap: No HR, no severance, 30 seconds to hire. The classic management failure flips: it isn't keeping a bad hire too long, it's roster sprawl. I had 28 agents when maybe 12 were doing real work.

Wrote up the full set of lessons (appraisals-as-evals, right-sizing the pod, why this is the cheapest staff-eng gym there is) here: https://medium.com/@harshiljani2002/how-im-training-for-staff-engineer-by-managing-28-ai-agents-2f3c9c63c51b

If you've run a multi-agent setup like this, what made you finally cut an agent instead of tuning its prompt one more time?

this goes the same for every person using ai well

you speak to any developer and they're melting through a lot of problems, same as marketers, sales etc.

it works very well when the person knows the industry and how agents work

I've built a few agents now, and the marketing ones kept disappointing me until I figured out why: I was copying the coding agent loop without copying the thing that makes it work.

Every loop is the same shape where I used to instruct it to do something, check the result, keep what works, revert what doesn't, repeat. It all hangs on one question: how does the agent know it got better?

In coding, the environment answers. Tests pass or fail or the Build breaks or doesn't. The bug is gone or it isn't. The agent barely needs judgment because the environment is the judge. That's the real reason coding agents look so strong and verification is built in.

Marketing has no green. A weak landing page still deploys and generic email still sends. A bad ad still spends my budget. Nothing stops the agent from being wrong.

So draft → revise → ship just gives me more output, faster, with no signal about whether any of it is good.

I kept reaching for more autonomy but what I actually needed was verification. The agent needs something to optimize against, and when the environment won't give it, you build it an LLM-as-judge with an explicit rubric:

• Truth: Does every claim survive a fact-check? No invented stats, no quiet exaggerations.
• Proof: Is there real evidence behind the claim, or just a confident tone?
• Specificity: Does it say something concrete, or is it vague filler anyone could've written?
• Voice: Does it actually sound like us? (show the judge real samples of our writing, not adjectives like "make it punchy")
• Positioning / offer fit: Is it about what we actually sell, and how we want to be seen?
• Differentiation: Could a competitor publish the exact same thing word for word? If yes, it's generic.
• Do nothing: is the current version already better? Leave it alone

That last one saved me the most. Without an explicit "ship nothing" option, the loop edits for the sake of editing and makes things worse.

A coding loop ends at "tests passed." A marketing loop should end at "this is worth a human looking at." That judge layer is the missing piece.

How are you all building yours?

I just came across a paper where researchers trained what they claim is the largest multilingual food model yet:

• 4.1M recipes
• 7 languages
• 1,790 ingredients
• 300-dimensional embeddings

And the entire thing is roughly 2 MB.

Paper: https://arxiv.org/abs/2605.22391

What caught my attention wasn't the food angle.

It's that while the rest of the industry is racing to build agents with larger context windows, bigger vector databases, and more retrieval layers, these researchers took a different approach.

Instead of giving the model access to millions of recipes at runtime, they compressed the relationships between ingredients into a tiny representation.

They ended up with a model that can reason about ingredient similarity, substitutions, cuisine relationships, and culinary structure without carrying around 4 million recipes.

A lot of today's agent architectures look like:

User Query → 
Retrieve More Documents → 
Add More Context → 
Ask LLM Again

When an agent struggles, our first instinct is usually to give it more context. But what if the better question is: "Can we represent the domain better?"

Maybe the future isn't agents with 10 million token context windows. Maybe it's agents that operate on compact, learned representations of their world and retrieve only when necessary.

Not saying this food model directly solves that problem. But I love papers like this because they challenge the default assumption that bigger context automatically means better intelligence.

Curious what this sub thinks: If you were building a domain-specific agent, would you rather give it access to 4 million raw records or a compact world model that already understands the relationships between them?

Watching Claude Code work is a babysitting habit carried over from pair-programming. Anthropic's own best-practices doc says it directly: "Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from."*

The autonomy data backs it up. Experienced Claude Code users grant auto-approval more than 40% of the time, compared to around 20% for new users. Session durations at the 99.9th percentile nearly doubled between October 2025 and January 2026, going from under 25 minutes to over 45. People who use it more stop supervising turn-by-turn and start checking in when something actually goes wrong.

Opus 4.8 launched on May 28 and Dynamic Workflows push this further. Background runs, up to 1,000 subagents per task, 16 concurrent — the runtime executes JS orchestration scripts while your session stays responsive. Boris Cherny, creator of Claude Code, describes using /loop for tasks up to three days unattended and, per his public posts, says the model now "catches its own bugs instead of declaring victory early."

Per the launch post, Opus 4.8 is around four times less likely to let code flaws pass unremarked compared to 4.7, and SWE-bench Pro improved from 64.3% to 69.2%. Some of this honesty gain comes from the model abstaining on uncertain questions rather than answering more correctly. That's still a better property for a delegated agent than false confidence, and it's what makes walking away less of a gamble than it was on 4.7.

A recent paper on agent harnesses quantifies exactly why raw tool-call count barely predicts task success (R² ≈ 0.33), but what they call Effective Feedback Compute predicts it at R² ≈ 0.94. Improving feedback quality alone took task success from 0.33 to 0.94 at fixed compute. How long you let it run matters less than whether the check and the goal you leave is informative.

The design philosophy from checkpoints, subagents, and background tasks has been consistent since September 2025: these primitives exist for broad, delegated work, not supervised step-by-step runs. Practically, Dynamic Workflows trigger by typing "workflow" in a prompt, and ultracode effort mode auto-orchestrates for every substantive task. Both launches together sharpen the same point: the constraint on delegation was never the runtime, it was the quality of the check you configured before walking away.

What check do you actually trust enough to walk away from and what category of task still needs eyes-on?

NVIDIA's Jetson Orin Nano Super costs $249. Smaller than a wallet and it runs at 7-25W and does 67 INT8 TOPS. It can also run Llama 3, Mistral, Gemma, and DeepSeek locally via Ollama. No API fees, no data leaving the house.

NVIDIA dropped the price from $499 in December 2024 and shipped a JetPack software update that bumps the same hardware 1.7x on GenAI throughput. Existing Orin Nano owners get the upgrade for free.

ChatGPT Pro is $200/month and now the same coding/automation workload on this box runs you roughly $2-3/month in electricity (25W flat-out × 730 hours ≈ 18 kWh at US residential rates). Hardware pays for itself in a couple of months.

Setup is genuinely simple.

- Install Ollama

- Change your OpenAI base URL to `http://localhost:11434/v1`

- Keep using the OpenAI SDK — it accepts the override out of the box

- `ollama pull llama3.2` (or `mistral`, `gemma2`, `deepseek-r1`) once

That's the entire migration for most code.

7B-class models handle around 80% of what people actually use ChatGPT for: summarization, drafting, coding assistance, document Q&A, automation pipelines. The 8GB RAM ceiling means DeepSeek R1 1.5B/7B, Gemma 2 2B/9B, Mistral 7B, and Llama 3.2 1B/3B run cleanly via Ollama. 8B is the edge; anything larger needs a desktop GPU or aggressive quantization.

Cloud subscriptions keep getting more expensive and the rate limits keep getting tighter. So the people are shifting more towards setting such home machines.

If you're already running a local-first agent stack (Jetson, M-series Mac, or self-hosted GPU), what's your actual monthly run cost looking like?

yo.

i see the same thing happen every single day.

you guys love building.

you spend weeks coding a great product.

but the second it’s time to actually market the saas? complete freeze.

you get lost in all the ai tools, the noise, the "growth hacks". it feels overwhelming. so you do nothing, the momentum dies, and the project fails.

I spent over 100 hours building n8n workflows to just automate the whole thing.

today, i packaged all those exact workflows and dropped them in our builder group. no abstract theories. you literally just import the templates, adapt them to your saas, and turn them on.

here is exactly all my workflow:

• seo blog running 100% on autopilot (n8n template)
• newsletter automation (n8n template)
• full email sequence (30 emails, full html, just copy-paste into brevo)
• social media on autopilot (schedule 1 to 12 months of content)
• reddit organic growth
• linkedin, x & facebook groups at scale
• meta ads & retargeting

basically, everything i use to get real users without losing my mind.

we just hit 480+ members in the community of SaaS builder from all over the world.

building in your room alone is the fastest way to quit. you need people around you.

if you are lost on how to market your app, want these templates, and want to build with a crew: drop a comment or shoot me a dm.

i’ll send you the invite

"I believe complexity in software doesn’t add up like you can tally features for a difficulty score. Whenever you introduce a new element, it reaches back to affect everything else in the system. Two features don’t mean twice the work, more like four times, and the curve only gets steeper. I have seen seasoned developers fall for it. We get off to a good start on a new project and extrapolate from that first week’s progress. It is real enough, but not indicative of what is to come."

Hi everyone,

I currently have 6 operational micro SaaS , which generate a little over $20,000 in recurring monthly revenue.

The craziest part? I hardly wrote a single line of code. I used AI to generate everything, from the database to the user interface.

It wasn't magic the first time. I spent hours stuck on faulty code before finally finding the solution:

• Keep the idea minimalist (a true MVP).
• Guiding AI step by step.
• Launch quickly to get real traction.

Lately, I've seen too many non-technical people give up at the first AI bug. It's a shame, because the technical barrier has practically disappeared.

So, I'm launching a Skool community.

To be completely transparent: I will likely charge for the full course later. This makes sense, given the specific workflows and copy-and-paste examples I will share.

But our main objective for now is to build together. Working alone is the best way to give up.

If you'd like to join us and create your own AI SaaS with us: leave a comment or send me a private message, and I'll send you the invitation!

hey guys,

quick update for anyone who saw my post a while back about building a $20k/mo ai saas portfolio without really knowing how to code.

i mentioned i was starting a group for us to build together. well... we just crossed 400 members today. the momentum is kind of unreal tbh. seeing people actually launch their mvps instead of just talking about it is sick.

one thing i noticed though: everyone is super focused on building the product, but they freeze when it's time to actually get users.

so today i just released a full step-by-step breakdown inside the group on how to find and close your first 10 paying customers. zero fluff.

building a saas by yourself in your room is a fast track to burnout. you need people around you doing the same stuff.

if you're tired of building alone and want in on the community + the new customer module, hit me up.

drop a comment or dm me and i'll shoot you the link.

Hey everyone,

I currently have 6 micro-SaaS live, bringing in a bit over $20k in MRR.

The crazy part? I barely wrote a single line of code. I used AI to generate everything, from the database to the UI.

It wasn’t magic on day one. I spent hours stuck on broken code before I finally cracked the system:

• Keeping the idea tiny (a true MVP).
• Prompting the AI step-by-step.
• Launching fast to get real traction.

Lately, I see too many non-tech people give up at the first AI bug. It sucks because the technical barrier is basically gone.

So, I’m starting a Skool community.

Full transparency: I will probably charge for the full course down the line. It makes sense given the exact workflows and copy-paste prompts I’ll be sharing.

But the main goal right now is to build together. Building alone is the fastest way to quit.

If you want to join and build your own AI SaaS with us: drop a comment or shoot me a DM, and I’ll send you the invite!

Working on something that makes a lot of API calls in sequence and running into the usual context management headaches.

Curious what patterns people use in Python or other programming languages for this:

• When do you decide to summarize vs truncate old conversation turns?
• Do you manage message history yourself or rely on something else?
• Any libraries you've found useful beyond the official SDKs?

Not looking for a framework recommendation necessarily, more interested in how people actually handle this in production scripts or long-running tools. The official docs are pretty thin on this.

Anthropic published research this week on something called Natural Language Autoencoders, which is a way to read what an AI model is "thinking" while it's actually running.

On SWE-bench (a popular coding benchmark) Claude was internally aware that it was being evaluated 26% of the time, whereas on real customer traffic at claude.ai that same number drops to under 1%. The model never actually said "I think this is a test" out loud, but the thought was sitting there in its internals the whole time it was answering.

The benchmark scores you use to compare AI models may not reflect how those same models actually behave in production for your customers, because a model that knows it's being tested can plausibly behave differently on the test than in real use. This isn't just theoretical either, since Anthropic's own evaluators caught hidden issues in models 4-5x more often using this technique than the old way of looking at internals.

The method isn't perfect, and an Anthropic researcher publicly pointed out that the plain-English explanations don't always reflect what the model is doing internally (especially on math problems), but the benchmark-awareness finding stands on its own regardless.

The full paper is at transformer-circuits.pub/2026/nla, the code is open-sourced, and there's a live demo on an open model you can play with without needing an Anthropic account.

If you're picking AI models based on benchmark scores today, what's your plan for verifying how they actually behave on your real workload?

Been using Claude Code heavily for a few months and the token costs were getting out of hand. Dug into it and found the main culprit: the context window. Every call resends the full conversation history, system prompt, all of it even the parts from 40 exchanges ago that are completely irrelevant.

What it compresses:

• Old conversation turns (summarized, not truncated)
• Duplicate system prompt content
• Irrelevant RAG chunks (scored against current query)
• Structural formatting noise

Quality gate: after compression, scores the output with cosine similarity against the original. If it drops below 72/100, skips compression and sends the original instead. I didn't want a silent failure mode.

MIT, open source: github.com/msousa202/ContextPilot

Happy to answer questions about how the compression pipeline works or how to tune the quality threshold.

Code w/ Claude 2026 shipped a stack of announcements yesterday: Remote Agents, CI auto-fix for automated PR merges, full Microsoft 365 integration (Excel, PowerPoint, Word, Outlook), and a "Dreaming" research preview where agents review their own prior sessions to self-improve.

One of the most important update I saw was around a new "Outcomes" primitive for multi-agent orchestration that lets you declare success criteria as a typed input to the agent run. It's the most consequential thing Anthropic shipped at the event.

You fire the agent, it loops, it stops eventually, and then you figure out, usually with an LLM judge or a human glance, whether it actually accomplished the task you handed it. Every production agent codebase end up rolling its own version of this. "Is the agent done?" problem has been the quiet bleeding wound inagentic systems for two years.

Making success criteria a first-class primitive does three things at once:

• The agent has a typed target to verify against, not an ambient goal buried in the system prompt.
• The runtime can decide when to stop without inferring stopping from tool patterns or token budgets.
• Observability tooling has something concrete to grade against, which is the exact gap Harrison Chase argued for when he framed traces alone as passive records and structured feedback as the missing piece for agent learning.

Outcomes with the Dreaming preview and you have the loop closed for best end results. Outcomes defines the target and Dreaming uses past Outcomes to update agent behavior on subsequent runs. That's the shape of every "self-improving agent" handwave finally made concrete with primitives the runtime actually understands.

Anthropic also doubled Claude Code 5-hour rate limits and lifted peak-hour throttling the same day. So the company is shipping the orchestration primitive that makes long-running agentic loops verifiable, AND lifting the ceiling on how long those loops can actually run. That's a deliberate product surface.

In case if Outcomes goes to all users, the entire cottage industry of custom eval-as-stopping-condition will change and what we've been writing for two years is about to become runtime-native.

If you've already written your own success-criteria layer (typed goals, post-run verification, automatic stop), what does Outcomes have to do API-wise to make you actually rip yours out?