Activity
Mon
Wed
Fri
Sun
Aug
Sep
Oct
Nov
Dec
Jan
Feb
Mar
Apr
May
Jun
Jul
What is this?
Less
More
Memberships
AI Automation Society
426.3k members • Free
AI Systems for Human Content
7.1k members • Free
Chase AI Community
72.6k members • Free
9 contributions to AI Automation Society
23h •
Quick one for the AIOS crowd
For those of you actually running an AIOS day to day, not just talking about it: is yours mostly a personal setup, or are you using it in client projects too? I've got mine wired across a few contexts (work, side builds, admin) and I'm curious whether people here keep it private or actually put it in front of clients. And if you do, do they know it's an AIOS running under the hood, or do they just see the output? Trying to get a sense of who's building for themselves vs who's productising it.
23h •
True or false?
Businesses don't care about the tool you use, they want the results, the outcome.
3 likes • 23h
Mostly false, and your instinct is right. It's a nice line for a landing page but it falls apart the second you're dealing with anything regulated or at scale. On a small one-off build, sure, nobody's checking under the bonnet. Deliver the thing, get paid, everyone's happy. But the bigger the project, the more the tool and the process become part of what they're buying. Enterprise clients ask about your stack because they have to live with it after you've gone. Who maintains it, does it lock them in, does it pass their security review, can their own people work with it. In banking or insurance I've had procurement teams reject a perfectly good outcome purely because the toolchain didn't fit their compliance requirements. The result was fine. The journey wasn't auditable, so it was a no. So it's not "results vs tools", it's that above a certain size the tools and the journey ARE part of the result. A great outcome you can't support, secure or explain isn't actually a great outcome to them. Small projects: they want the outcome. Big projects: they're buying how you got there too.
Nov '25 •
Sales Contracts Pre-Validated Before Legal Review 🔥
Sales pipeline template tracks deals beautifully. Lead scoring, follow-ups, meeting scheduling, deal progression - all automated. Contract stage? Bottleneck. Every contract sat in legal review for 2-3 days. Not because legal was slow. Because half the contracts had basic policy violations that sales should've caught. Payment terms wrong. Liability limits off. Terms legal always rejects. Sales sent anyway. Legal sent back. Sales fixed. Resubmitted. Another 2 days. Average: 4-5 days at contract stage. Killing deal velocity. I ADDED CONTRACT PRE-VALIDATION: Before legal sees contracts, workflow checks against company policy automatically. - Payment terms match policy? Check. - Liability within acceptable range? Check. - SLAs achievable? Check. - Standard terms present? Check. - ALL compliant → Send to legal (clean contracts only) - Issues found → Back to sales to fix first WHAT HAPPENED: Legal review time: 2-3 days → 1 day Why? They're only seeing contracts that are actually ready. Sales catches mistakes BEFORE bothering legal. Average contract stage: 4-5 days → 1-2 days THE MATH: - 3 days saved per deal - 12 deals monthly - 36 days of cycle time eliminated LEGAL TEAM FEEDBACK: "Contracts arriving are actually reviewable now. Not spending time on basic policy compliance." Sales team feedback: "Getting instant policy checks helps us write better contracts from the start." VALIDATION CHECKS: - Payment terms against approved ranges - Discount levels within authority limits - Liability caps match policy - Required clauses present - Renewal terms standard The sales pipeline template handled deal flow perfectly. Just needed contract intelligence at the critical stage. BUILD TIME: 2 hours to configure policy rules VALUE: 3-day cycle time reduction per deal One extension. Sales cycle shortened by 60%. How many days do your contracts spend in legal review? Could pre-validation help?
0 likes • 27d
one should think of geo related issues, each country might have different laws...
May '25 •
Which model do you use?
With Claude 4 just dropping, interested to hear which LLm peeps are using as their go to for AI agents? Any reason not to use Claude 4 for general purpose use? Thanks in advance 👍
2 likes • Jun 14
My honest take: I don't pick one model, I pick one per job, and that single shift saved me more money and grief than any benchmark ever did. For the reasoning-heavy parts of an agent, the planning, the judgement calls, the bits where one wrong turn cascades into a mess, I default to the strongest Claude I can justify. It's the most reliable I've used for staying coherent over long multi-step runs, which is exactly where most agents quietly fall apart. But the second a step is routine and high-volume, classifying, extracting, summarising the same shape of thing a thousand times over, paying top-model prices is just lighting money on fire. For those I drop to a smaller, faster model, and a fair chunk of it I run locally on my own box and pay nothing at all. So to your real question: no, there's no good reason not to make Claude your general-purpose default, it's a very strong all-rounder and a sensible place to start. The trap is using your most expensive model for every step inside an agent and then wondering why the bill and the latency are brutal once you scale. One more thing that took me far too long to learn: the model is rarely what's holding an agent back. Nine times out of ten it's the context I fed it and the tools I gave it, not the brain. A mid-tier model with clean context will beat a frontier model flailing around blind every time. Mix and match, and only reach for the big gun when the step genuinely earns it.
Jun 14 •
/Goal vs /Brainstorming
How would you guys compare these 2 skills? When would you use one over the other?
4 likes • Jun 14
This used to trip me up as well, until I stopped seeing them as a choice and started seeing them as a sequence. The way it clicked for me: /Brainstorming is for when I don't really know what I'm building yet. The idea is half formed, I'm hand-waving, and I need something to sit across from me and ask the awkward questions I would have happily skipped. It pulls the spec out of my head and breaks the messy parts down before I waste a single token building the wrong thing. /Goal is the opposite energy. It's for when I already know exactly what "done" looks like and I'm just sick of babysitting. You set the finish line and walk away instead of typing "keep going" for the fortieth time. The bit I learned the hard way: if you point /Goal at a fuzzy target, it will cheerfully tell you it's finished when it has built you a shoebox. Not because it lied to you, but because your definition of done was weak. /Goal is only ever as good as the thinking that went in front of it. So the rule I use now is simple. Brainstorm until you can write a one-line definition of done you'd actually bet money on, then hand that to /Goal. Not sure what you're building, start with brainstorming. Crystal clear and just want it shipped, go straight to goal. Took me a few wasted runs to figure that out, so hopefully it saves someone else the tokens.
1-9 of 9
Online now
Joined Jun 5, 2026
Powered by