Launched this week
YAGNI
Proactive agent teams you manage like humans
485 followers
Proactive agent teams you manage like humans
485 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
@jackcollinshq look forward to hearing more and following the product journey 💪
YAGNI
@l_hall Thank you so much! I really appreciate it!
@jackcollinshq Really thoughtful launch; thanks for sharing the guardrails, Jack. Quick test for the “Team” idea: if YAGNI drafts a Team for my company and I notice it missed an important constraint, what’s the simplest way to teach that constraint so future actions respect it? How long until the Team stops making the same mistake, and can I audit every change the Team makes while it’s learning?
YAGNI
@swati_paliwal Great test, and it's the everyday loop we most wanted to get right. There are two ways to teach it, depending on whether you want to correct or to state a standing rule.
If you just fix it in the moment, edit the draft before approving, that single correction becomes an example the Team sees the next time it does that kind of work. You don't have to repeat yourself for it to take.
If it's a real constraint you want respected every time ("never contact a customer without an account owner CC'd," say), you add it as a rule in the Team's Playbook and it applies on the very next action. There's no threshold to clear. The learning loop that watches for repeated edits is only for catching patterns you didn't state out loud. Anything you state directly is immediate. So the answer to "how long until it stops making the same mistake" is: next action, for anything you tell it explicitly.
On auditing while it learns, this is where the earned-trust ladder does double duty. A new Team starts with everything drafted for your approval, nothing ships on its own, so in the early period auditing every change isn't a separate feature you turn on, it's just the default state of a Team that hasn't earned autonomy yet. You see each action before it happens. On top of that, the Playbook is append-only, so the standing rules and how they've changed stay visible rather than getting silently overwritten, and the Team's actions land in a feed you can scroll.
One honest note so I'm not overselling it: a Playbook rule is a top-priority standing instruction the Team follows, not a hard-coded runtime block. For the constraints where a slip would actually hurt, the guardrails do the hard enforcement independently of any rule text: anything irreversible, anything touching money, anything going out broadly stays human-approved no matter what. So the rule shapes behavior, and the ceilings are the backstop that doesn't rely on the model remembering.
@jackcollinshq Really enjoyed reading the maker’s story. It feels like this product came from years of managing teams rather than just trying to wrap another language model in a new interface. If you can make this reliable enough for day to day operations, I think you’ll have something people can genuinely build around. Good luck with the launch!
YAGNI
@josh_bennett1 Thank you for the kind words! That's certainly how I'm thinking about it. This is the tool I am using myself to run YAGNI, and I think the potential is huge for other teams as well. Thanks again!
Congrats on the launch, @jackcollinshq — framing this as "manage like humans" instead of "hire an AI employee" genuinely reframes the category for me.
The piece I keep circling on is the Number each Team is measured on. Giving a Team a single metric to own is exactly how you'd brief a real hire, but it's also how you get Goodhart problems: a Sales Team measured on "qualified meetings/mo" has every incentive to quietly loosen what counts as qualified over time, and the Receipts would all still look clean. How do you keep a Team from optimizing the metric at the expense of the intent behind it, is there anything watching the gap between the Number climbing and the actual downstream outcome (closed deals, not just booked meetings)?
YAGNI
@mitch_belsley1 This is the best kind of hard question, because you're right that a single Number plus clean Receipts is exactly where Goodhart creeps in. Let me split it into the part we structurally prevent and the part that's still a human's job, because I'd rather be straight than pretend we've closed the whole loop.
What we prevent: a Team cannot change its own Number, or what counts toward it. The definition is human-owned. An agent has no way to quietly redefine "qualified" from "took a real sales call" to "opened an email." That change is a deliberate human edit, not something a Team can propose or drift into on its own. So the specific move you're describing, a Team loosening its own bar over time, is blocked at the structural level. The goalposts aren't the agent's to move.
Where the judgment still lives with a human: watching whether the Number is still predicting the real outcome. If booked meetings climb while closed deals stay flat, that divergence is exactly the thing a manager should be looking at, and today we deliberately keep that read with the person, not an automated scorer. What we give them to do it well is Receipts, which verify that concrete things actually happened (a reply landed, a payment posted, a deal stage moved) instead of trusting that the work got done. Tying those downstream receipts more tightly to the Number, so the metric has to keep earning its status as a good proxy, is exactly where this goes next, and honestly you've framed the reason for it better than our own notes do.
So: the agent can't move the goalposts, and whether the goalposts still point at reality is a call we keep with the manager, backed by verified receipts rather than vibes.
Appreciate you pushing precisely where it matters - let me know if I can add more context!
@jackcollinshq This is a genuinely satisfying answer; thank you for taking the question seriously instead of hand-waving it. The distinction you drew is the crux: making the Number and its definition human-owned so a Team can't quietly redefine "qualified" closes off the drift I was most worried about, and I really respect that you separated what you've structurally solved from what's still a human judgment call rather than claiming the whole loop is closed. Tying receipts more tightly to the Number so the metric has to keep earning its status as a good proxy sounds like exactly the right next step. Appreciate the thoughtful reply and congrats again on the launch!
YAGNI
@mitch_belsley1 Absolutely! I’m glad I could help, and thanks for the great question!
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!
@jackcollinshq This is such a thoughtful answer — thank you for going this deep, I really appreciate it. The reversal-as-tiebreaker piece is the one I keep coming back to. Since a reversal can land weeks later, or only surface downstream, I'd love to understand how the ladder reaches back to the specific approval it should count against — especially with the "evidence has to be recent" rule in play. Just curious how you think about that timing gap. Thanks again for laying all of this out so generously 🙏
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.
The track record model is the right idea, and honestly a better answer than most agent products give to the trust question. But the hard part is measuring it. How do you actually know a run went well?
In support this is where it gets tricky for us. A customer who got a wrong answer usually does not complain, they just leave, or reopen the same thing a week later. So the easy signals (no complaint, ticket closed) look fine while the agent is quietly doing damage. The track record can read clean and still be wrong.
What signal do you use to decide a run succeeded? Human review of every run at the start, or something the agent grades itself on?
YAGNI
@jernej_jan_kocica Great insight and thank you for the thoughtful question.
First of all, the Teams start in the "Training" phase. The success signal is never the agent grading itself, and it's never the absence of a complaint. Closed ticket and no-complaint are explicitly not counted as wins that count towards promotion to the next "Supervised" authority. At the start it's simple: a new Team drafts everything for review and ships nothing on its own, so early on you're looking at each run, not a proxy.
But I think your point is that, once it's running in Supervised or Autonomous, how do I really know it's doing the right thing?
Receipts are at least a partial answer here... a verified record that a concrete thing actually happened, written back onto the source record itself, the ticket or the contact, not a side dashboard. So the proof of a run lives where the work lives. And if something looked fine but proves wrong later, undoing it claws back the trust that run earned rather than leaving the record falsely clean.
Above the per-run layer, the briefing is the top-level review: a periodic roll-up of what the Team did and what held, so someone is reading the forest, not just approving trees. And all of it is interrogable in the YAGNI chat, you can just ask a Team about any run and pull the receipts.
The one thing I won't oversell: turning a week-later reopen into an automatic score is genuinely hard, and no system invents a signal reality doesn't emit. What we're careful about is never reading silence as success, which is the exact failure you're describing.
If you're up for it, I'd love to discuss this workflow more deeply with you to make sure we have the right "Trust" posture for the Autonomous workflows.
Thanks again for the great question!
@jackcollinshq Receipts written back onto the source record is the right answer, the proof should live where the work lives. And the trust claw-back for runs that prove wrong later is a good mechanism.
One thing from our side: the week-later reopen usually does not come back on the same channel. A customer who got a wrong chat answer writes an email instead, or an Instagram message. So even honest reopen tracking undercounts unless you tie the identities together across channels.
Thanks for the offer to go deeper, I would like that but my time is very short these days. Good luck with the launch.
The Training → Supervised → Autonomous ladder, and especially counting edits-you-shipped as stronger evidence than a silent approval, is a sharper solution than most "trust the agent" products attempt. I've been circling the same problem from the read-only side rather than the action side: an AI Chief of Staff for founders running multiple businesses, where instead of earning autonomy to act, it earns the right to state something as fact vs. flag it as "Needs Review." Reversals eating earned trust is a great mechanic. Have you found any Team types where even Supervised-level trust turned out to be miscalibrated in hindsight, cases where the reversal signal came too late to prevent real damage?
YAGNI
@stacywycof83995 Really like the read-only reframing. "Earn the right to state something as fact vs flag it for review" is its own ladder, and arguably a harder one, since a wrong fact does its damage silently where a wrong action at least tends to leave a mark.
On miscalibration: the cases I care most about aren't the ones you catch late, they're the ones you design so trust can never reach them. Because reversal is a lagging signal by nature, we treat some categories as permanently past what earned trust can buy: anything irreversible with wide blast (moving money, a broadcast send, a delete) stays human-approved no matter how clean the record. The honest answer to "where does the reversal come too late" is that for those classes we assume it always does, and never let a track record buy its way past them.
For your side, that's the transferable bit: reversal is a backstop, never the primary guard for anything whose damage lands on the first instance. The read-only analog is that some claim types should never be auto-stated as fact regardless of track record, because a confident wrong assertion harms on first read, before any correction fires. Match the ceiling to how recoverable the mistake is, not to how well the agent has behaved. Would genuinely like to compare notes as you push on this.
Thank you for your thoughtful question!
@jackcollinshq "match the ceiling to how recoverable the mistake is, not to how well the agent has behaved" is the clearest version of this idea I've heard, going to steal that framing internally (with credit!). We landed on the same hard line for Monitor Only vs. Verified: some categories (anything touching money, legal filings, or anything that goes out to a customer/investor) just never graduate past "flag it," no matter how many times it's been right before. What tripped us up longer than I'd like to admit was resisting the temptation to let a good streak quietly raise the ceiling on its own. Would genuinely like to compare notes sometime on how you decided which categories get frozen at that ceiling permanently vs. which ones are allowed to climb.
YAGNI
@stacywycof83995 Sounds great Stacy, would be happy to compare notes! I'll message you privately then. Good luck and stay in touch!
the 3-similar-edits threshold is a smart way to avoid over-fitting to one correction, but what happens after a rule gets promoted and it turns out to be wrong two weeks later, like it was right for the cases you saw but breaks on an edge case nobody corrected yet. is there a way to see which rules are actually firing and roll one back, or do you have to notice the bad output first and trace it back to the rule that caused it?
YAGNI
@omri_ben_shoham1 Good scenario, and it really splits into three questions: can you see the rule firing, can you roll it back, and do you have to be the one who notices.
Seeing and rolling back: yes to both, and they're easy. Every rule is plain-language text in the Team's playbook, and each one carries its own track record, how often it was in play and whether the work under it got approved clean, edited, or undone. Retiring one is a single action that takes effect on the next run, and it's append-only and reversible, so you can pull a rule and reinstate it later without losing anything.
The trace-back is mostly automated, which I think is the part you're really asking about. When the Team drafts something, we fingerprint which rules were in context for it. So when an output later gets edited or reversed, that correction is already linked back to the rules that shaped it, you're not hand-tracing "which rule caused this." A rule that starts correlating with reversals gets proactively flagged for retirement, with its record attached.
The honest limit is the one baked into your example: that flag is driven by correction signals. For an edge case nobody has hit or corrected yet, there's no signal, so nothing can pre-detect it, you can't catch an error the world hasn't produced. What the system does is compress the loop once the first bad output surfaces: the offending rule is already in frame, and repeated hits escalate it from "here's a candidate" to an automatic retirement suggestion. So you're not reverse-engineering from scratch, but you are still the one who catches the first miss.
Thanks for the thoughtful question, and please let me know if I can add any more context!