Launching today
YAGNI
Proactive agent teams you manage like humans
269 followers
Proactive agent teams you manage like humans
269 followers
AI today is reactive: it waits for your next prompt. YAGNI is proactive agent Teams you manage like people. Give a Team responsibilities and guardrails, review its work, and it earns autonomy through a track record you can read, while you keep the calls that matter. Paste your company's URL and YAGNI drafts your first team in seconds. You aren't gonna need more software. You need a team that gets better every week. Become a self-improving company.
YAGNI
Hey Product Hunt 👋 Jack here, founder of YAGNI.
The best teams I've been on ran on trust. It's what makes a team fast, and it's the hardest thing to build and the easiest to break. I've spent twelve years building and running teams, through two acquisitions, a Techstars batch, and orgs across healthcare, government, and startups big and small, B2C and B2B. That lesson held everywhere.
AI changed my own output more than any tool ever has. But it brought the trust problem back in a new form. More output means a worse signal-to-noise ratio, and the moment you try to put agents to work inside a business you hit a wall: where do you even start? Every tool assumes you'll be directive. Either you prompt each task ("do this thing"), or you wire up an if-this-then-that graph and hope you predicted the work correctly. That's not how anyone actually runs a team.
YAGNI takes the approach I learned managing people. You hand a Team a real slice of the business to own and give it the structure you'd give a new hire: Responsibilities, a Number it's measured on, Commitments with real deadlines, and Rhythms (its recurring work). Then you manage the early work closely. It drafts, you edit and approve, and every correction teaches it how you'd do it next time.
As its track record grows, it climbs a ladder you control: Training → Supervised → Autonomous. At the top it carries the routine, reversible work on its own, every action leaves a Receipt from the source system proving where things actually stand, and you stay in the loop for the calls that matter. Irreversible and high-risk actions stay behind your approval forever, at every level. That's a design commitment, not a model limitation.
Two things I decided early, because I'd want to know them as a buyer. First, it runs exclusively on open-weight models, so it's cheap enough to let Teams work continuously instead of sparingly. Second, it only uses first-party, official integrations, so your data is read where it lives, never sold, never used to train a model.
Humans and Teams work off the same context, and it all collates onto your Front Page, published as a Brief morning, midday, and evening. Monday's status meeting starts at the decisions instead of the recap. Dive into any work with a persistent chat sidebar to so that you always have the context to make the decision.
Who it's for: founders and operators who've become the bottleneck (the person everything routes through), and lean teams who want real leverage from agents without babysitting them.
What to try first, and don't sign up: go to https://yagni.app/build-your-team, paste your company's website, and about 30 seconds later YAGNI hands you a Brief with your first Teams already drafted: what it would own, which tools it would read, and what it would do in week one. Free, anonymous, no card. If the Team it drafts is wrong for your business, I genuinely want to hear why.
Paid plans start at $99/mo when you're ready to put a Team to work. Get 60% off ANY plan for 6 months with code YAGNIPH (60% because we can offer AT LEAST 60% savings of frontier models).
I'll be here all day. Ask me the hard ones: pricing, security, "isn't this just a wrapper," what happens when it screws up. I'd rather answer those in public than in a sales call.
@jackcollinshq I’m really curious about the “every correction teaches it” part. What actually happens after I edit or reject something? Does YAGNI save it as memory, turn it into a rule, or use it in some other way? And how do you avoid teaching the agent the wrong general lesson from one very specific case?
YAGNI
@gleb_rosev Thanks for the question! Corrections work at two levels:
Level one: when you edit a draft before approving it, YAGNI saves the before/after pair. That single correction shows up as an example in context the next time the Team drafts that same kind of thing. So one edit teaches immediately, but only as "here's how they revised this exact kind of output", never as a general rule.
Level two: a correction only graduates into a rule when it's a pattern. A background pass looks for three or more similar edits (similar in both what it drafted and how you changed it) before it proposes a rule. The rule is written in plain language, starts applying so the correction compounds forward, and shows up in your Feed as a proposal you can adopt or dismiss. Nothing is learned invisibly... you can read every rule the system is following.
For code, the correction signal is the merge itself. When a Team's PR gets merged, YAGNI diffs what the agent proposed against what actually landed; whatever you changed before merging is captured as a correction, automatically. Mid-run steers ("actually, use the existing helper") are banked as decisions with your consent. Both are fed back into future runs as cited sources: the agent has to cite which past decision or correction informed its answer, so you can always see why it did what it did. Corrections don't kick in until there are enough of them to be a pattern, so one unusual PR doesn't become a doctrine.
Rules also have to keep earning their spot. Every rule is tracked against outcomes it was in context for. If a rule correlates with you reversing the agent's work, or simply never fires, YAGNI suggests retiring it. So a wrong lesson doesn't just sit there forever; the same evidence loop that created it can kill it.
@jackcollinshq This is actually a really solid approach. I especially like that one correction stays an example and only becomes a rule after the same pattern appears several times.
And making the agent cite which previous correction or decision influenced the output is a great idea. Usually the worst part of these learning systems is that at some point the agent changes its behavior and you have no idea why 😁
YAGNI
@gleb_rosev Awesome, I'm glad you think so! Thanks again Gleb
The Training → Supervised → Autonomous ladder is the part I keep thinking about — earning autonomy from a readable track record is such a thoughtful framing for trusting agents with real work.
A couple of gentle questions from an evals angle, if you have a moment. What signal actually promotes a Team up a rung — is it approval rate, and if so, how do you gently tell apart "approved because it was right" from "approved because I was busy and didn't look too closely"? I imagine that's a tricky line to draw.
And on the adversarial review step: does that reviewer run on the same open-weight model as the executor? Would love to understand how you keep it from leaning toward a rubber stamp when critic and author might share the same blind spots.
Really nice launch, congrats @jackcollinshq 👌
YAGNI
@akbar_b Both of these hit exactly where the design effort went, so happy to go deep. Sorry if it's too deep :)
On promotion: the signal is not approval rate alone. Three kinds of outcomes feed the ladder. Clean approvals count for it. Edits you shipped also count for it. Reversals, where a human had to undo the agent's work, count against it. A Team levels up on the running total of those, and three separate checks have to pass at once: the total must clear a bar that scales with the Team's caution setting and with the riskiest action type it has actually touched, the reversal rate has to stay under a cap, and the evidence has to be recent. Even then, clearing the bar only produces a suggestion; a human confirms every level change. The system never promotes itself.
And yes, the busy-approval problem is real. We don't pretend to know how carefully you looked before clicking yes. Two things keep lazy approvals from quietly building trust.
First, the ladder actually values your edits more than your "yes". An edit you shipped is judgment you clearly exercised, so trust doesn't accumulate from unexamined approvals alone.
Second, reality is the tiebreaker. If you approved something without looking and it turned out wrong, undoing it counts as a reversal, which eats the earned evidence and can knock the Team down a level. A rubber-stamped yes only becomes lasting trust if nothing ever comes back to bite. And in the meantime, the actions where a careless yes would really hurt are exactly the ones that always stay in front of you, with an undo window or as a draft you have to approve.
On the reviewer: the critic and the author are not the same setup. We put the strongest model on the steps that decide what to do and catch what's wrong (planning and review), and a different one on the writing. But honestly, the model split is the smaller half of the defense. What matters more is structure.
The review fans out to three separate reviewers, each with a different brief: is it correct, does it solve what was asked, and will it hold up. Each one starts from a fresh context and can read and run the work or code but not touch it. That means none of them inherit the author's working context, which is where the rationalizations live. The correctness reviewer is non-negotiable: if it doesn't run, the whole review round fails rather than passing on a partial check. Serious findings send the work back to be fixed, and the loop repeats until they're cleared. And the last reviewer is always a human... that final gate never goes away.
I hope that helps - let me know if you have more questions or if I can provide any more context. Thank you!
Really like this, @jackcollinshq, the "earn autonomy rule by rule" model is the part most agent tools get wrong. They expect you to trust the thing on day one, here it's earned off a track record instead. What was the hardest part of getting that Training -> Supervised -> Autonomous ladder right, and how do you keep reviews from sliding into rubber-stamping once a Team is approved for a lot of work?
YAGNI
@augustoody Great question!
Deciding on the ladder itself was the first challenge! I started naively just building AI automation, but the ladder came out of real user feedback, and I think it's become one of the most valuable parts of the product.
Beyond that, it was deciding what counts as evidence. Our first version only counted clean approvals, and it had an embarrassing flaw: nobody ever graduated. Because that's not how a good manager behaves. You don't approve a draft untouched, you reshape it a little and ship it. So Teams were doing steadily better work, getting edited-then-shipped every time, and the trust score sat at zero. The fix was realizing an edit you shipped is stronger evidence than a blind yes. You clearly looked at it, exercised judgment, and put your name on the result. Once edits counted, the ladder started matching how delegation actually feels.
The second hard part was accepting that some things should never graduate. How much trust a Team has earned and what a given action can ever be trusted with are two separate questions. Wiring money, mass sends, deleting things, a Team changing its own configuration: those stay human-approved forever, no matter how good the track record gets.
On rubber-stamping: my honest answer is that the ladder is the anti-rubber-stamping mechanism. Rubber-stamping happens when your queue fills up with low-stakes asks and your attention gets trained to wave things through. Earned autonomy exists to move the routine stuff out of the queue entirely, so what still reaches you is short and worth reading. And when attention does slip, reality collects the debt: if something you waved through gets undone later, that reversal eats the earned trust and can knock the Team down a level. So inattentive approving doesn't quietly compound, it gets repaid. There's also a weekly digest that shows how often you're editing versus approving, which is a decent mirror for whether you've gone quiet on review.
Congrats @jackcollinshq👏 on hitting the front page! the choice to run this entirely on open-weight models is a massive selling point for keeping costs scalable, are you guys hosting these models on your own cloud compute nodes or can we host the agent workers inside our own private cloud setup for compliance?
YAGNI
@priya_kushwaha1 Thank you so much! Right now we are hosting our own as well as using US-hosted providers like Fireworks.ai and Together.ai for the open-weight model inference.
We can offer BYOK for those who want to manage their own LLM inference, and happy to support private cloud setup for compliance as well!
Let me know if you have any other questions - and thanks again!
@jackcollinshq that's awesome BYOK and private cloud support are huge pluses for enterprise users.
all the best 👏
I run Claude Code and a couple of agents most of the day, so "manage like humans" resonates. The part I would love to see solved: knowing when an agent is genuinely blocked and waiting versus just thinking. Does the management layer surface that, or is it more about task assignment?
YAGNI
@virko_kask glad to hear it resonates with you!
Yes, work that "Needs You" is flagged very clearly in the app.
The YAGNI Teams work through a loop like this for most of their work:
Map - gather context about the work item)
Plan - YAGNI presents a plan for your review and edits
Execute - Complete the work
Adversarial Review - Specific adversarial agents probe the work for issues, especially with the context of your previous work and corrections
Final Review - your place to review the work before it's sent / pushed / merged
At the Plan and Final Review steps the work has a specific "Needs You" flag that automatically routes it to the top of the list. Additionally, we collate everything that needs you into a simple "Feed" so you can easily and efficiently unblock your YAGNI teams.
I hope that answers your question, but happy to provide more context as well. I appreciate it!
the rule-promotion system (3+ similar edits before it becomes a rule) is the part that stands out to me, most "agent memory" pitches are vague about how corrections actually turn into behavior change, this is the first concrete answer I've seen. one thing I'd want to know: if two different people on the same team review and correct the same kind of work differently, does the Team end up with conflicting rules, or does it pick up whoever's corrections happen to hit the 3-similar-edits threshold first?
YAGNI
@galdayan I totally agree about the vague "agent memory" pitches. That was a big driving force for designing this (hopefully) clearer architecture.
To answer your question:
Similarity is required on both sides of the edit: what the agent drafted AND how it was revised. So two people correcting the same kind of work in different directions don't blend into one averaged rule... they form separate patterns. Whichever pattern reaches three similar edits first gets proposed first, but the other can still reach the threshold and get proposed too. In practice, the second reviewer's corrections become a competing rule proposal.
Which means yes, you can end up with two rules in tension. What we refuse to do is resolve that silently. Every rule is plain language in one shared playbook per Team, every proposal surfaces in the Feed, and members of that Team can dismiss or retire either one. YAGNI also remembers which rules were in play for each piece of work. If work done under a rule keeps getting reversed by a human, that rule gets flagged for retirement with evidence attached.
To take a step back though, the Team has one playbook in the same way a human team has one style guide. If two reviewers genuinely disagree about how the work should be done, that's a management conversation the system should surface and make legible, not hide behind the scenes. That's my opinion at least!
Let me know if you have any other questions!
I like how YAGNI emphasizes proactive agent teams, but I'm curious - how do you envision the 'guardrails' working in practice? Would love to see some examples of what that looks like in a real-world setting.
YAGNI
@aymnart Happy to add some extra context here...
Guardrails in YAGNI aren't a settings page of toggles. Two mechanics combine on every single action.
First, every action a Team can take carries a risk profile: is it reversible, how wide is the blast radius, does it touch money, etc. That profile sets a permanent ceiling on how autonomously that action can ever run. In practice:
Internal writes, scheduling, drafting a PR: reversible and contained, so this is the class that can eventually run autonomously. Still logged to the Feed with receipts, never silent.
A 1:1 customer email: contained but not reversible, so it's capped at supervised. It's surfaced per action with an undo window no matter how much trust the Team has earned.
Wiring money, blasting the whole list, deleting data: irreversible and high blast, so draft-only forever. A human approves every single one, and no amount of earned trust lifts that.
A Team changing its own configuration (its rhythms, its sources) is pinned at draft-only too. A Team never rewires itself silently.
Second, within those ceilings autonomy is earned, not granted. Every Team starts in training, where it drafts everything. Clean approvals and edits you shipped build evidence, reversals count against it, and riskier action types require more evidence. When the bar is met, YAGNI suggests the level up and a human confirms it. The system never promotes itself.
So the effective permission on any action is the minimum of what the Team has earned and what that action type can ever be trusted with. Proactive never means unattended.
Let me know if I can provide any more context, and thanks for the question!