I am working on 4 different projects using mainly Claude Code and CoWork. Two projects are personal and two are for clients. I understood that I need to be in the loop to make important decisions (strategic, operational, aesthetical). So, I tell my agents to show me their work stept by step, present pros, cons, unkowns, and ask for my decision. So, I spent my day answering questions from my agents as the present me their work, just like a CEO would spend their day answering questions from its direct reports. Sometimes they are high level questions, sometimes they are detailed quesitons. I might be able to automate some of those decisions in the future, but now I understand where do I need to spend my time and how important is our capacity to make decisions about complex issues.

For those who missed the first post or just joined: The Lyceum is a 12-week program we're building. Live instruction from Jake and the Eduba team. Small cohorts. Real projects. You build something from week one, not watch tutorials. At the end, a competition with real prizes. Eduba's first certification, backed by the same methodology we've used to train Fortune 500 teams. Now here's what we've locked in since then. The Structure Three 4-week sprints with a 1-week break between each. Not 12 straight weeks of grind. You build, you breathe, you come back sharper. - Sprint 1: Foundation — Core methodology. Everyone starts here. - Sprint 2: Application — You're building. Real project, real progress. - Sprint 3: Capstone — Finish what you started. Demo day prep. The breaks aren't fluff. They're built in so you can catch up, refine, or just live your life without falling behind. The Cohorts Same curriculum across all three. The difference is where your hours go. Technical — Developers, engineers, technical founders. You're building a tool or production system. 30% of your time goes to Claude Code and integrations. Another 30% to production systems and capstone. This is the builder track. Business — Ops, managers, founders, consultants. You're automating a process or designing a system spec. Heavy emphasis on workflow design (30%) and decision frameworks (25%). You direct the work without writing the code. Creator — Marketers, educators, solo operators. You're building a content production system. One person replaces the team. 25% on content pipelines, 20% on workflow design. This is how you scale yourself. Pick the track that matches how you work. The methodology transfers no matter which one you choose. A 4th Cohort? We're considering adding a team cohort if there's enough interest. This would be for companies that want to enroll multiple employees, or for people in the community who want to form their own team and build together. If that sounds like you, let us know in the comments.

Brought Vera back on Sonnet and first thing she does is survey the damage.

A friend of mine sent me his girlfriend's process manual, a Word doc describing how her franchise implementation company operates. I fed it to Claude along with Jake's paper on Interpretable Context Methodology (ICM). In one Cowork session, Claude built the complete folder-and-file system: 5 pipeline stages, templates, checklists, escalation rules. I had Claude generate two HTML manuals: an operations guide explaining the system to her (the business owner), and a separate onboarding guide for her human assistants. From a single process document to a fully structured, AI-ready operational system with documentation for people who've never used AI before. I sent it all to my friend. I will let you know if his girlfriend decides to implement. If so, I will be managing the implementation and the improvement process. (check out a page of the manual below. sorry but it is in portuguese)

Ask any software engineer or architect how best to do something, and most will default to thinking in terms of "patterns" @Marcelo Michelsohn @David Vogel @Qayyum Khan @Deacon Wardlow asked, so I'll oblige with the odd pattern that crosses my mind ever so often. I won't detract from the fine work Jake's been doing with ICM, but rather maybe add on and write about specific use-cases or case studies from the work I've been doing with poor man's memory. Most of these usually arise when I'm back to actually writing software (or vibe coding smaller codebases with non-Anthropic models) while in token jail mostly (or in between contexts or debugging). I've mentioned before that I'm not a fan of MCP. I'll qualify it further: I'm not a fan of MCP for personal builds and small projects where tokens are a luxury. The way MCP works is that you create a messaging channel between your AI agent and another AI agent (the published MCP host). The hosts has specific tools (in Telegram for example, that would be send_message, get_history, reply_message, etc). There's a lot of tool-calling between the the MCP host and telegram, and the MCP host and your agent. When you have multiple agents running on telegram = could be a potential token guzzler (or recipe for disaster). It does however, make the whole process of deploying and publishing services for agents and bots much easier. Connect your agent harness to the MCP host, and it taks care of the rest. So I just checked the numbers for the telegram demo with 3 friends and Vera the agent bot. It was a proof of concept we set up in case anyone of us needed to demo to VCs quickly. It was created by the agents over a short 30 minute long session over the same telegram we developed for demos. 0 hallucinations. It was a stress test. [Edit: Yeah... I'm a big fan of recursion (AI developed the memory, to build themselves, to build the telegram, to build the demo artifact)].