"Agent self improvement" is a really powerful concept. In short: have agents review past work, identify where they went wrong, and propose updates to skills and AGENTS.md files to prevent future failures. Here's a multi-agent system you can implement: 1. Have scorer agents review past conversations and assign pass/fail grades along metrics you define: code quality, efficiency, task compliance, etc. This can be a subagent swarm reviewing in batches, or run as an automation using hooks with your agent harness 2. Let self-improvement agents review conversations with "failing" scores, receiving both the raw transcript and a "report" generated by the scorer agent. The agent reviews those failures and creates a PR to update skills or AGENTS.md files, citing failed runs as evidence for changes

I’m making a course on software factories with @vikvang1. What should it include?

We @warpdotdev are teaming up with @warpdotco to host a poker tournament this Wednesday evening in NYC! Luma link & buy-in details in thread 😁

🌉 Excited to announce the awesome speaker lineup 🔥 for the Code Engineering event in San Francisco 🌁 Previous Agent Engineering HQ @AgentEngHQ Harness Engineering event in June pulled more than 300 people (1100+ registered) and flooded the Loft. Code Engineering is the next and you cannot find a better lineup than this. The speakers from the coding agent labs itself who know the ropes. 💻 Code Engineering: From Coding Agents to Software Factories 🗓️ Tuesday, October 27 · 6:00–8:30 PM 📍 AWS Builder Loft, San Francisco 🌁 🎙️ Speakers • Seth Karten (@sethkarten) - Prime Intellect @PrimeIntellect Prime Agent: a self-improving RLM harness with swarm communication • Ben Holmes @BHolmesDev - Warp @warpdotdev Building a self-improving software factory • Sydney Runkle @sydneyrunkle - LangChain (@LangChain) Building agents that work like coding agents and generalizing those primitives beyond coding • Andrey Risukhin (@AndreyRisuka - Factory @FactoryAI) Reducing coding harness latency with the Software Factory If you are in San Francisco 🌉 on 27th October, you shouldn't miss this event. 🙏 RSVP Now as we have limited seats. Checkout the detailed talk and abstract: 👉 luma.com/cico2dxy

I'll be speaking at @aiDotEngineer NYC about this on October 14th!

Thanks @BHolmesDev and @zachlloydtweets for the @warpdotdev swag!

Software factories should be built on an infrastructure stack that is open, composable and defined in code: Open == works with any model, agent and hosting configuration Composable == you can adopt part or all of the stack, and use the pieces however you want Defined in code == factory state is versioned, testable, and revertible Let’s break this down layer by layer: Factories-as-code Define your agent infrastructure in a version-controlled file like factory.yaml: agent configuration, runners, repository access, external integrations (Slack, Jira), webhooks (Grafana, Sentry) and automation triggers (crons, taskboard changes, PR updates, etc). The format matters less than having a code-based approach that allows versioned changes to the factory definition. Versioning enables benchmarking, A/B testing and rollbacks. It’s Terraform for factories. Data and context One level up sits the Context Layer. It includes internal MCPs and CLIs, agent memories (blob storage, skill files), conversation logs, access logs, and agent rules / skills. If you use a third-party context layer, you should be able to store all its data on your infrastructure. No outside provider should train on this data. ZDR is a must. Compute Next is the Compute Layer, where your agents run. Centralized runs need remote dev environments, likely defined in Docker or k8s. They should be pausable and resumable, with state portable across machines. You should also be able to connect computer use models to test the apps agents build in your remote dev environments. This is useful for reproduction, verification and prototyping. Inference The Inference Layer should support any model and agent so you can evolve and test your factory configuration to optimize quality, cost and speed. It should support frontier and open-weight models plus multiple agent harnesses. Improvement An important part of any factory is the Improvement Infrastructure, which ensures software gets built at higher quality and lower cost over time. Start by tracking DORA metrics like cost-per-PR and qualitative metrics like code quality and efficiency using LLM-as-a-judge. Once you have these metrics, close the loop: Self-improvement: agents automatically find failure points and suggest skill improvements. Benchmarking: test suites with varied configs measure how the model and harness combinations perform on real work. Orchestration Your factory needs a control plane to launch agents, manage crons, drive work to subagents, and provide live sessions for human steering. Access Work enters and leaves through UIs, a direct MCP, and third-party surfaces like code forges and knowledge work tools. All access points should use unified APIs for launching work, monitoring progress, updating the factory definition, and more. This benefits humans and agents. - As we move to automated development, think of software factories as an Infrastructure Stack. If you are exploring this approach, we would love to chat.

That SpaceX merger is really paying off with this animation...

GPT 6 Sol and Luna are now available in the Warp Terminal and the Warp Agent CLI

There’s a stage between local coding agents and full-blown software factories that I think of as “multi-player interactive agents” In this world: 1/ Development is still done by individuals prompting agents directly, not by automation 2/ The prompting happens in public tools like Slack/Teams, Jira/Linear, Github/Gitlab 3/ Because the prompting is public, folks can tag in collaborators to help provide context to agents (e.g. “can @joe_teammate tell the agent why we built this component this way?”) You get some of the benefits of factories because 1/ If you set this up right, your agents are in the cloud, which provides security and control and tracking 2/ You can create a learning loop around these interactions But it’s not fully a “factory” because folks still work in the old interactive style of prompting and steering agents, just from a collaborative surface in the cloud. It’s a good stepping stone though.

Building factories multi-model is the best way to do it. GLM 5.3 Flash has been seriously impressive as a foreman router so far

Three aspects of any good software factory stack: configured-as-code, multi-model + multi-harness, and complete data ownership. Factories-as-code: define your factory configuration in version-controlled files. This enables testing of different factory configurations to see which are most efficient, highest quality, etc. Multi-model & multi-harness: you should make sure that your factories are able to use the latest models, both frontier and open-weight, and use different coding agent harnesses like Claude Code and Codex. Data ownership: you should make sure you store and own all data coming out of your factory - this is the raw material for improving its operations.

If you’ve been looking for a good intro to software factories, watch this

Live demo of factory engineering on How I AI with @clairevo, showing off scoring, self-improvement, and benchmarking (and also me being inept at using Figma) lennysnewsletter.com/p/how-w…

These are the metrics engineers will start optimizing: - Agent code quality - Agent token efficiency - Agent task compliance And so on. It's factory engineering

This is the strategy behind /skill-doctor (the skill that improves your agent skills). 1. Main agent grabs your agent sessions 2. Subagents fan out to score and judge each run 3. Main agent uses failed runs to suggest improvements to skills and AGENTS.md

Here's a 45-second TL;DR on Jev. I find the core idea beautifully simple, but the video made it really hard to understand. Hope you find it helpful.

And we're live! Come join us 🔴 luma.com/warp-8vtl