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 little about me: I'm from Salta, in northern Argentina. By day I'm the tech lead and product owner of SaltaCompra, the public e-procurement system of the Province of Salta. On the side I run Cuenta Norte, a small consultancy mixing accounting, software and AI for local businesses. I think in systems more than in code: I design, decide, and let agents do most of the implementation. 🎯 My current goal: Turn the way I work with AI agents into repeatable products, both for small business clients and for the public sector, where trust, traceability and "who can see what" matter as much as the output. 💪 What I'm currently building/working on: My whole workspace already runs on folders + context files (CLAUDE.md, CONTEXT.md, decision records), so ICM felt like home the moment I read about it. On top of that I've built my own Claude Code plugins to orchestrate agents in parallel, an AI assistant that sits on top of a client's ERP, and a knowledge base that distills videos into reusable notes. 🤔 My biggest struggle or question right now: Packaging. My system works great for me, but my clients and public officials won't ever open a terminal. How do you take an ICM-style setup and hand it to non-technical people in a way they can use and trust, with clear limits on what data each person or agent can reach? Let's get it! 🚀

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.

I joined this community four weeks ago already believing that ICM had huge potential. I decided to dive in headfirst. I was already and AI Engineer working on multi-agent systems, but ICM became my new standard. A. The Foundation I started with The Foundation, and it taught me far more than I expected. Not only about ICM, but about AI systems and how to build them with clearer structure, context, and intent. B. From Learning to Building I started experimenting with ICMs for databases, streamlined video production, sales-discovery chatbots, and shopping assistants. Some were practical. Others were completely random experiments designed to help me understand what was possible. But things quickly moved beyond experiments. C. ICM Helped Me Land a New Job I used ICM in a demo assignment during an interview. I aced the assignment, got the job, and start next month. D. Six Months of Work Rebuilt in One Week At my current job, I had built a system combining a crawler, vector database, and multi-agent deployment. The original system took me six months to develop. I rebuilt it using ICM in just one week. The ICM version is slightly slower, but the quality of its answers is noticeably better. The client agreed that the improvement was worth it. E. Less Complexity, Faster Delivery For another client, I had planned a traditional multi-agent system. After redesigning the solution with ICM, I now estimate that the development time will be cut roughly in half. F. I have also taken on two new clients In the past, I might have worried about whether I could deliver what I envisioned. Now, knowing what ICM makes possible, I feel confident taking these projects head-on and delivering genuinely strong products. G. Learning, Contributing, and Growing Along the way, I joined VIP, learned a ton, and got to use EDUBA, which has been a great learning experience as well. I also reached #1 on the leaderboard and earned lifetime VIP. More importantly, being active in this community has pushed me to keep learning, experimenting, sharing, and building.

This community is large and it moves fast. That's the good part and it's also the problem: valuable posts get buried, the same questions get re-asked instead of found, and spammers show up wherever there's an audience. These guidelines are what keeps the room worth showing up to. Read them once. You won't need them again, because most of this is what you'd do anyway. New here? Start with Jake's welcome post and the Foundation course. This post is about how we behave, not where to begin. 1. Build in public. Post the thing while it's half working. A half-finished build is more useful to everyone else than the polished writeup you'll never get around to, and you'll get corrected before you've spent a week going the wrong way. 2. Teach what you learn. The day you figure something out is the day you're best at explaining it, because you still remember exactly what confused you. A month later you've forgotten the hard part and your explanation gets worse. If you cracked something this week, that's a post. Nobody has to earn the right to ask a question here, but this place only works because people come back and answer them once they can. 3. Ask good questions. Specific beats polite. "How should I structure this?" gets three vague answers. "I have a 40 file client folder, the model keeps loading the wrong context file, here's my CLAUDE.md" gets a real one. Say what you tried, what happened, and what you expected instead. A more in depth guide: https://dontasktoask.com The flip side of this: "Anyone here?", "Help please", and one line questions with no context may get removed. Not to be harsh, but because nobody can answer them. 4. Give credit. If you built on someone's skill, template, folder structure or comment, tag them. It costs you nothing and it's the reason people keep publishing their work here instead of keeping it. A lot of the best material in this community started as somebody's reply on somebody else's post.