Been doing some refining with my agent I created and posted about a week or so ago now and I thought I'd share one of their reports below. Essentially this is something I created just to update me on what's happening in the frontier labs, what CEOs are doing, just to teach me about the business landscape around AI and some things that are relevant to the work I'm doing. As well as the whole process of building this, setting up this self-scoring rubric, which rates these news stories against the relevance to me. The whole building process taught me a lot of value as well. So just thought I'd share this and maybe you'll find some interesting news in here that you haven't seen!

A pad of scrap paper beside the keyboard has done more for my throughput than most of the tooling I changed this year. The minutes a model spends building are the minutes to spend deciding what happens after it lands. - The next sequence - the two or three work orders after this one, written while this one runs. - Notes on the output - what to keep and what to challenge, marked as you read rather than after. - Designs - page layouts, folder trees, flows. Faster to draw than to describe. The dead time in an agentic session is real. A job runs for a few minutes and there are three things you can do with that window: watch it, interrupt it, or think. Watching teaches you nothing and interrupting usually costs a rerun. Writing by hand does something a second chat window does not. The keyboard pulls you back into the work; paper keeps you above it, which is the seat you are supposed to be in while an agent is running. The reading half matters more than the planning half. Marking what to challenge as an output comes in, rather than reaching the end and reconstructing it, is the difference between a next instruction that corrects course and one that just says carry on. The bit I have not solved is getting any of it back into the system. Everything on that pad is orientation the workspace never sees. One of the synced writing tablets pointed at a folder would close that - handwriting arriving as context on the next prompt, and the notes logged as part of the record of how a build actually went. If anyone here has wired one up, I want to hear how. Genuinely think that is one of the more interesting unbuilt pieces sitting in plain sight...

A model reviewing its own work is not a review. It is the same judgement run twice, and it agrees with itself both times. - Maker and checker are separate passes - whatever produced the work does not get to grade it. - Fresh context, not just a fresh prompt - a different chat, ideally a different model, carrying none of the reasoning that built the thing. - A number it cannot argue with - a test, a diff, a count. Prose review on its own will find reasons to approve. The failure mode is not that a model lies to you. It is that it is still holding every assumption that produced the work, so asking whether the work is good just reasons forward from those assumptions and lands where it landed the first time. I have had this go wrong with real stakes on it. Folder bloat that survived an adversarial review and two further passes on the strongest model I had. A multi-repo restructure proposed off one of three files the model had actually read. A Git migration recommended on the grounds that we had a backup, which we had made ourselves an hour earlier. Every one of those cleared a self-check first. What changed it was making the check structural rather than something I remember to do. In my YouTube workspace no finding enters the register until it has been surfaced to me at the close of the query that produced it, so the system proposes a belief and a human commits it. In phronesis the distillation pass runs behind an eval gate allowed to reject the commit outright, so the pass that writes the profile is never the pass that decides the profile is good. Metrics carry the other half. A verdict written in prose can always be argued into place, a count or a failing test cannot - if the only evidence something worked is a paragraph the model wrote about its own output, there is no evidence. Where has a self-review waved something through that it should have caught, and what do you actually use as the outside check - a second model, a fresh chat, a test, someone else in here? More interested in the practical setups than the principle.

After a call with @Danney Tee who kindly demo'd his full system at Reelix and gave me inspiration for what he had done. I decided to have a bit of fun and create my own mechanism, scoping in on one of the areas, which is AI being able to watch and analyze videos.... So I built codename "Argus" -- Still in development but showing some insanely promising results! Argus is the layer that watches a published video and writes down what was on screen, second by second. It is also the cleanest ICM structure I have built, for a boring reason: a pipeline already has stages, so you let the folders be them. - The stages - 01 to 08 in flow order. Each is a folder holding its own script, its own CONTEXT.md of local rules, and its own output. - The root context - only the rules that genuinely cross every stage. What a frame is, how a missing value is recorded, what the system never claims. - _config - the channel. Vocabularies, the editorial ladder, the thresholds. The stages hold the engine, the config holds the channel. The flow reads straight off the folder names. Stages 01 to 05 describe: fetch the video, cut it into frames, measure the frames, ask a model what is happening in each second, roll it up into buckets. Stage 06 synchronises, mapping the editorial plan for that video onto what was described. Stages 07 and 08 derive, joining to the retention curve and rendering the written product, and they are not allowed to add any new observation - only to compute from what came before. The ICM part is that a job sent to stage 03 opens stage 03. It reads that folder's rules and its inputs, and inherits nothing else except the handful of root rules that actually apply everywhere. No stage carries the whole pipeline in its head. That is the difference between a pipeline in folders and one long instruction file trying to describe eight things at once, and it is why I can hand a stage to a job without re-explaining the system around it.

Hi, I am trying a new approach - if you want to connect a company data brain from a server do you train a team to use it with which front desk ? people who are not technical