Part of my education journey is to teach also my knowledge folder information. I would like to increase my education rate by creating a pipeline, from a url youtube video -->> aggent analyse and get information-->> create a md file I have everything working my last step that are doing manually is the step 1. So is anyone has something to let an agent read, watch, listen a youtube video ?

my question in 1 sentence : Should an ICM agent be allowed to propose changes to relationships (fields pointing one record at another, like ownership) or only to scalar values (self-contained data such as amounts, dates, statuses and free text) — and is that distinction even a legitimate permission boundary, given that Jake's model draws the line on role, route and sensitivity, never on field type? ------------------------- The context I run an ICM where the catalog is generated from the system that holds the actual records, and where the agent can propose changes back through a human gate. Reads flow one way, proposals flow the other, and nothing is written without me approving it. When I built the proposal path, I made a decision I now think was wrong. I allowed the agent to propose changes to values — amounts, statuses, dates, free text — but I blocked it from proposing changes to relationships: the fields that point one record at another. My reasoning at the time was that a pointer is structural, and structure should be changed deliberately, through the interface, not through text. Re-reading the ICM Architect material, I no longer think that distinction holds. Jake's permission model is built on role ("agents inherit the access of the role they act for, never more"), on route ("the permission lives in the routing, at the data layer or along the route"), and on sensitivity ("shelve by sensitivity"). Never on the technical type of a field. And relationships are not second-class in his model. Invariant 8: "Links make it a graph… the edges are what let an AI move through your work the way you do." His own node template carries owner: <accountable person or role> right next to consumes: and produces: wikilinks — all of it ordinary frontmatter. So I may have invented a governance rule that is really just an implementation constraint wearing a costume. --- The concrete example The field is ownership — who is accountable for a record. Today: Me : "Who is accountable for this one?"

Has anyone here successfully recreated an Obsidian-like graph view for their own project? I'm trying to build something similar, but I can't use Obsidian because I don't want users to have direct access to or be able to modify the underlying data. I'm finding it really difficult to bring my vision to life, so I'd love to hear about your approach, the stack you used, or any advice you might have.

I've been thinking about something that challenges a lot of assumptions we have about building internal business tools. The observation: Most internal enterprise applications (CRMs, case management, dashboards) are essentially CRUD interfaces sitting on top of a database. You build forms, tables, buttons, modals — all so humans can read and write structured data. This takes weeks/months to build, requires frontend skills, and creates maintenance debt. But here's what I'm noticing: when your team operates primarily through AI assistants (Claude Code, Cursor, etc.), they're already reading and writing structured files. Markdown with YAML frontmatter becomes a database row. A folder structure becomes a schema. A file becomes a record. The AI reads context from files, writes outputs to files, and the human reviews in the same environment. The question that keeps nagging me: If your internal operators spend 80%+ of their time in a terminal/AI environment anyway, do they actually need a web UI at all? Could a well-structured filesystem (folders = tables, files = records, YAML frontmatter = fields) serve as the entire "application" for internal operations? Where I think this works: - Small teams (3-10 people) where everyone uses AI tools daily - Structured workflows where files follow strict templates/schemas - Operations that are mostly "read context → think → write output" - Teams where the AI assistant IS the primary interface, not a browser Where I think it breaks down (and I'd love to be challenged on this) = Bottleneck = Constraints 1. Governance & permissions — Who can approve what? A filesystem doesn't have row-level permissions. You'd need something on top (even minimal) to enforce "only person X can validate this change." 2. External stakeholders — Clients, partners, investors who will never open a terminal. They need something visual, even if it's read-only. 3. CEO/decision-maker dashboards — Aggregated views ("how many active cases? what's the pipeline value?") are hard to get from ls | wc -l. Someone at the top needs a summary layer.

Hi all, Before I get to my questions, I want to thank Jake for such a valuable resource in his ICM / F&F method. I am an AI and coding newbie, and this has definitely put me on the fast track. I knew I needed something like this, I just didn't know how to even start looking for it, and then the YouTube algorithm served it up for me. The moment I saw what Jake was teaching, I knew it was my next step in the journey. Thank you! On to my questions. I have gone through the Foundation Course, and I have the full Workspace-Blueprint template. The three-layer method (Map, rooms, tools) has become how I actually work, and I have been running it for a little while on smaller projects. Here is my situation. I am building the operating system for a multi-industry business group, and it has grown into several distinct domains: - an identity and philosophy layer: governing principles, values, and leadership and management philosophy, synthesized from a body of books and courses, - a knowledge layer: a large reference library plus custom tools that extract and organize knowledge from books and transcripts (several thousand files), - a research layer, - an operations layer: SOPs and playbooks for running the businesses, - a learning layer that captures lessons and feeds improvements back in, - a governance layer that holds the enterprise map. Right now this lives across roughly ten separate Claude projects that grew organically. Some began as tools, some as libraries, and each became its own project. Many are stages in a workflow. So, work completed in one "stage" needs to move into another. Most of this was built before I discovered Jake. I am fairly certain I need to reorganize what I have already built, and I am also considering turning some, if not all, of the skills I have created into file-based workflows. The method is taught at the scale of one folder with a few rooms, and mine is well past that, so I want to be sure I am applying it correctly rather than drifting into the "too many workspaces" problem at the project level.