I have been building my infrastructure and orchestration layers by hand rather than adopting something ready-made, and the main return has not been the system itself, it has been understanding exactly where it breaks. What I do not have is a clear picture of the wider landscape, so this is a genuine question rather than an argument. What building it myself has actually given me: - The failure modes first hand - I know where it breaks because I am the one who broke it. - The repass - every month or two I go back over the whole thing, heavy at the time, and it compounds. - No black boxes - when something goes wrong I already know which layer owns it. - It stays mine - no dependency on anyone else's roadmap, pricing or decisions. The repass is the part I would defend hardest. Every one to two months I go back over the infrastructure and the orchestration properly, and it is genuinely painful while I am in it. But each time I am looking at decisions I made when I understood less than I do now, and I can see exactly why they were wrong. That loop has taught me more than any amount of reading about it ever would have. Doing what I do now, the only cost to me is my 20x max plan with Claude. No other non-self hosted models, API fees or anything. Just me, Claude in VScode terminals, and wispr flow. I am considering just experimenting with the likes of Hermes and co, just for the learning experience anyways - just wanted to hear from others and feel this is a good place to do so! So the question, and I would especially like it from people further along than me who have experienced more of this. If you are running Hermes or anything similar, what did it give you that you could not reasonably have built yourself, and did you lose anything by not having built it - the understanding of your own system, or the ability to change it once it stopped fitting? Or have I misunderstood the split / missed the point?

I’m curious how much autonomy everyone gives AI in their workflows. Do you mostly use AI as a tool where you approve each meaningful step, or do you let it make decisions and continue working without checking in with you? I’ve been thinking about where that line should be. For those of you building with AI regularly, how much freedom do you actually give it? What can it do without asking you first, and where do you still require a human decision?

That is it... That is the entire post... Anyone else? Also what have you done? - I found a smarter room and now I feel like I am back at square 1 #excitement

Nobody can describe their own judgement. Everybody can run it instantly on a concrete case. That gap is the whole reason "describe your voice in five adjectives" produces profiles that read like everyone else's, and the reason every edit you make to an AI draft is worth more than the finished piece. I have been running a rough version of a voice layer across a few ventures for months, mostly for producing messages in my own voice. It works by feel, which is a different thing from working reliably. So I took the mechanism apart properly. Three things that came out of it and transfer to anyone doing this: - Contrast over description. Never ask what someone's voice is. Show two versions of the same piece and ask which is more them, then ask why. The choice is one bit. The reason is what generalises. - Edits are the data. Your draft is the rejected version, their edit is the chosen one, and the diff localises exactly what judgement changed. Most people keep only the final text, which throws the signal away. - Boundaries, not points. "Be direct" applies everywhere, including where you would not. "Direct with peers, softened one notch when correcting someone publicly" carries its condition, so it transfers to cases it never saw. A voice layer is not programming. Nothing executes. A rule you write does not get run, it shifts probabilities, and the practical shape is roughly 95 percent compliance with a tail that no additional rule removes. Everything else follows from that. You build for the tail, an inspection step sits after generation permanently, and the job is making inspection cheap rather than making it unnecessary. I ran the research as seven parallel chats, one per knowledge element: mechanism and limits, the encoding stack, elicitation, representation, evaluation, crossovers, and the research base. Split on dependency structure rather than topic, because they consume nothing from each other, so they were safe to run at once and cheap to correct. Each closed with a file in the same fixed output contract, which is what made seven separate outputs merge instead of contradict.

For those of you already working with AI/automation clients, what does your behind-the-scenes client onboarding and delivery system look like? I understand the discovery side. What I'm trying to build is a clean operational framework for what happens once a client starts moving forward. Specifically, I'm curious how you handle things like: • Client folder/workspace structure • Discovery notes → scope → build handoff • Credentials and access • Client-provided assets/information • Project status and task tracking • Testing and client approvals • Documentation of automations/agents/workflows • Launch/go-live checklist • Training and handoff • Ongoing support/maintenance If you have a standard folder structure, checklist, SOP, or client lifecycle that you actually use, I'd love to see how you've organized it. I'm less interested in the sales process and more interested in the operational infrastructure that keeps a client engagement organized from discovery through handoff.