🙋 A little about me: I’m a Québécois running travel brands that sell excursions and tours on Roatán Island, Honduras. I’m not a developer, but I run most of my business with Claude Code: websites, SEO, lead follow-up, automations. 🎯 My current goal: Sell more excursions with less manual work, by having AI agents handle the repeating tasks reliably. 💪 What I’m currently building/working on: One ICM workspace that holds all my brands, plus the shared automation and resources. Every folder has its own CONTEXT.md contract. This week I added an automatic check that catches broken links the moment an agent creates them. 🤔 My biggest struggle or question right now: Keeping the structure clean when several agent sessions work in parallel. Each one drops files in the wrong place and nobody cleans up. How do you keep your ICM from drifting over time? Let’s get it! 🚀

I've quoted more of these projects this year than I've won, and I'll admit it has been deflating. It would be easier for me to take if they had been bad ideas, but they weren't. They were problems worth solving. Someone inside a company had found a real problem, built something with an AI tool that actually worked, and then came to us for help getting it ready for real use. Then it stopped, and the reason is some version of "that's not in our budget." I should say up front that taking AI pilots live is work my agency now sells, so I have a stake in this and you should read the rest with that in mind. But I don't think I'm the one who feels this the most. I think it's the builders, the people on staff in sales or marketing or operations who used the tools their company gave them to make something useful, watched it work, and then watched it go nowhere. If that's you, the easy conclusion is that your idea wasn't good enough. I've come to think that's usually the wrong conclusion, and I want to explain why, starting with something that happened to me long before any of this was called AI. 𝐈'𝐯𝐞 𝐛𝐞𝐞𝐧 𝐨𝐧 𝐭𝐡𝐞 𝐨𝐭𝐡𝐞𝐫 𝐬𝐢𝐝𝐞 𝐨𝐟 𝐭𝐡𝐢𝐬 In 2002 I was a systems administrator at Philips, working out of the Chicago office while the rest of the IT department sat in Seattle. One of my first assignments was to evaluate new copiers, and the money for those copiers was coming out of the operations budget. While I was working on that, I learned that the order management team was photocopying hundred-page order packets every time a deal closed and shipping them overnight to the reps in the field, which was costing them a lot of time and a lot of money. I've written before about how I came across that problem, so here I'll stick to what happened after I had a fix for it. The new copiers could scan to PDF, and the order data was already being exported every night into an Access database, so the pieces of a fix were sitting right there. I took the idea to IT and asked for help, and they wouldn't put a team behind it. Looking back, I can see how that happened. The money for the copiers belonged to operations, the problem belonged to sales and order fulfillment, and the skills to fix it belonged to IT, and there was nothing connecting the three.

Hi all, I'm Phil. I run IT procurement at a large multinational, and I've just moved up to VIP after a few months in the community. I found Jake through his video on folders over agents. What I'm working on is a second brain for my own job: how new requirements come in from the business, deals, RFPs and the category plan, in one structure. Session 10 helped with that. Jake's point was that the right context beats all context, and my habit is to give the model everything. So my first job is to decide what each piece of work actually needs to read. Looking forward to the High Teas and to meeting you all. Phil

A few weeks ago I posted here about an assistant on top of a client's ERP. The best feedback I got was about permissions and writes: map each key to what that person may see, and keep the approval outside the model. This is what came out of that. It's called Puente ("bridge" in Spanish), and it's a product of my consultancy, Cuenta Norte. 🌉 The product Puente is a remote MCP server. Each person adds it to their own Claude app as a custom connector, on the phone, the web or the desktop (I've also tested it from ChatGPT). No terminal, no install, no new app to learn. Packaging was my big question when I joined, and this is my current answer: the screen is the Claude app they already have. Connecting to the system is not the interesting part. Odoo has an API, an in-house ERP has one too. Puente adds the three things nobody ships with it: 1. Scope per person. It knows who is calling and what that person may see. A sales rep reaches their own customers and orders. The owner reads everyone's but changes only his own. It's decided once, in one place, and a call that arrives without a real identity sees nothing. 2. A brake on writes. The model never writes. It proposes, the person gets a card inside the chat showing exactly what will change, and only the person approves. Each approval works once, and on one installation it also asks for a PIN. 3. Memory and a log. The company's context lives in folders by role, ICM-style, so what someone teaches the assistant stays with the role when the person leaves. Anything shared goes through the same brake as a write. And every call is recorded: who, what, when. 🏗️ One product, two installations The product is the core: identity, brake, card, log, context. It doesn't know any client exists. An installation is what belongs to one client: the adapter to their system, their context, their deployment. One codebase, a core plus one folder per client, and a test goes red if one client's folder reaches into another's. Today there are two installations on the same core:

A few days ago in my intro I asked how you take a folder + context setup and hand it to people who will never open a terminal. Here's what I actually built for a group of companies. In the first half of October the two owners made about 340 calls through it. The setup: - The owners use the Claude desktop app (Cowork). Each one has their own folder with context files and skills that explain the business and how to ask for data. - The agent never touches the data directly. Everything goes through what I call "the gate": a small HTTP server inside the company's network, with no AI inside. - The gate has one key per person and a read-only database user with timeouts and row caps. - Through it the assistant can reach the ERP database, the ERP source code, stored documents (purchase orders, delivery notes, invoices), a supplier price explorer and the purchasing inbox. - The inbox is the only place it can act: send, reply, label, archive. Every action shows an exact preview and waits for an explicit "yes". No permanent delete. The part I like most: the gate learns from use. When the owners ask something new, the assistant saves a recipe in the gate (how to answer that kind of question), shared by both owners and versioned with who, when and why. And every call is logged centrally with the question that triggered it, so I can see how they actually use it and improve it from there. What they actually used it for this month: - Pricing a deal: how competitors priced similar items in the past and whether they win on cost or on margin, crossed with our supplier price engine down to the manufacturer's part number, so they quote with prices that work and pick the supplier that fits best given each one's terms. - Insurance bonds: which ones are finished and can be returned, plus the email to the insurer with the purchase order and delivery notes attached. - Purchase status: which orders aren't fully received, invoiced or paid. - Month-end control: which months are still not locked against the filed tax return, per company and tax.