Public city · 14 published
Mind City
A living atlas of published work and the connections between it.
MMind City4 villages · 14 artifacts
Surveying the open world…
Published artifacts14 visible
PRThin skills, sharp tools — model-agnostic agent orchestrationThree thin skills plus two CLIs replace five Codex rulebooks; one bundle for every harness.ProjectAgent SystemsSkillsPRCodex Orchestration SkillsI recently overhauled my Codex orchestration skills and cut the whole system back to just two: `teamwork` for bounded multi-agent work and `governed-delivery` for tracked repository changes that really need custody, exact-head review, or an external delivery gate.
This is a deliberate move away from the larger cast of named roles, runtime hooks, and state machinery I had built. Ordinary work should stay ordinary. Teamwork should load when parallel agents will materially help, and Governed Delivery should load when the risk of a merge, deploy, migration, or other external action earns the extra structure.
I am trying this setup now to see whether the smaller instruction surface makes Codex more predictable and easier to maintain without losing the boundaries I care about. The attached field note reflects the current in-progress v2 working tree; the released `main` branch is still v1.0.0, so this is an experiment rather than a claim that v2 has shipped.ProjectAgent SystemsCodex SkillsLECaching in LLM agent systemsI read [Luke Parker’s post](https://x.com/LukeParkerDev/status/2080045430109556772) and ended up looking more closely at a question I keep bumping into: if an orchestrator is long-running, does it keep getting prompt-cache benefits?
The distinction that helped me is that the thread, the harness context, and the provider cache are separate things. A dormant thread is not spending tokens or keeping a provider cache warm. When it wakes, the next request can still hit if the early prefix is unchanged and the provider’s current retention and routing rules line up, but compaction, changed tools, new early instructions, or elapsed time can make it cold.
I wanted one guide that keeps the model’s in-generation KV cache, cross-request prefix caching, semantic caching, and ordinary tool caches from blurring together.LearningAgent SystemsLLM InferenceLEThe new rules of context engineering for Claude 5 models[Thariq Shihipar’s article](https://x.com/trq212/status/2080710971228918066) argues that newer Claude models change the context-engineering tradeoff: less duplicated rule-setting, more model judgement, interface design, progressive disclosure, and high-fidelity references.
One concrete reported result is that Anthropic removed over 80% of Claude Code’s system prompt for newer models with no measurable loss on its coding evaluations. The attached note keeps the article’s five “then/now” shifts together and maps the intended jobs of the system prompt, CLAUDE.md, skills and tools, references, and memory. It also keeps the evidence boundary visible: this is the author’s report, not an independently published benchmark.LearningAgent SystemsContext EngineeringLETowards Automating Eval EngineeringI read [Viv’s “Towards Automating Eval Engineering”](https://x.com/Vtrivedy10/status/2079976006644072796), about a skill that builds evals from an agent repository and its traces.
What stands out is that it does not try to one-shot the eval. It interviews the user, builds a Harbor task, and then checks both the agent and verifier trajectories for shortcuts. I like the idea of turning real failures into durable tests; I just want the loop to stay small enough that the eval system does not become another thing to constantly maintain.LearningAgent SystemsEval EngineeringLEWhy We're BuzzingI read [jack’s “why we’re buzzing”](https://x.com/jack/status/2080056638820450400), about Buzz, an open-source workspace that keeps people, agents, conversations, code, and approvals in one signed record.
The part I keep thinking about is the context problem. Agents can only help with what they can see, and we lose a lot between chat, code, CI, and review tools. I am curious how much of Buzz requires replacing the whole workspace versus making the seams between the tools I already use more coherent.LearningAgent SystemsAgent ContextWOBuilding a Small Language ModelI have started experimenting with a desktop application that lets me build and train my own small language model from scratch. I want to understand the whole process visually, especially what each setting is really changing and how the different stages fit together.
The attached field guide maps the path from licensed text and a custom tokenizer through random weights, pre-training, checkpoints, sampling, chat fine-tuning, and evaluation. This is still an experiment and a way for me to make the system less abstract; I am not claiming that the model has finished training or produced results yet.WorkflowLanguage Model TrainingSmall Language ModelsVICodex Micro — First LayoutI’m configuring my Codex Micro to see whether a small physical controller can make my Codex workflow quicker without becoming another setup I have to constantly maintain.
What I’m trying:
- Keep active work visible through the six agent keys.
- Put the basic Codex loop close at hand: talk, send, review, approve, start a new chat, and branch.
- See which controls actually become muscle memory before building out more layers.
Current setup:
- Agent keys: Priority chats.
- Command keys: Talk, Send, Approve, New chat, Review, Branch.
- Joystick: Plan up, Review right, Terminal down, Browser left.
- Dial: Reasoning only.
What I’m watching for:
- Which keys I reach for without thinking and which ones I forget.
- Whether Priority chats is better than fixed projects.
- Whether Review on both a command key and the joystick is redundant.
- Whether the dial is more useful for reasoning effort or composer navigation.
How I plan to optimize it:
- Use this layout for a week before making larger changes.
- Change keys based on repeated or missed actions, not theoretical usefulness.
- Keep Layer 1 aligned with the physical keycaps.
- Add browser, editor, terminal, and Mac layers only when a real repeated workflow earns them.
- Keep pushes, deploys, destructive commands, and other risky actions off single presses.
Building: Control Surfaces.VisualControl SurfacesCodex MicroVIBlack Signal CockpitI wanted one place to see what my agents are doing across the different harnesses I am running through Herdr. Black Signal Cockpit keeps every agent visible and adds session, model, tool, VCS, and worker details when a harness publishes them.VisualPiAgent SystemsVIBlack Signal ReviewI have been exploring JJ inside [Pi](/city/pi) and wanted the review loop to live closer to the agent. Black Signal Review puts the current change, diffs, local comments, GitHub state, and feedback back to the agent in one terminal panel. I am still figuring out which parts of this workflow stick, so drafts stay local and anything external requires confirmation.VisualPiCode ReviewVIBlack Signal Lab: The Experiment Console for My Pi HarnessA visual tour of Black Signal Lab, the metadata-only experiment console for my Pi harness.Visualpiblack signalVIAgent Swarms — Model EconomicsMy dylanmccavitt/skills repo was relatively close to this proposed structure in the sense that routing agents correctly, was the focus for an autonomous loop. I''m taking pieces of this article and implementing it in to my skills repo with some missing gaps that this currently brought up.Visualagent swarmsmodel economicsNOCleaning my agent configurationsA reflection on simplifying Codex agent configuration to reduce hidden context, improve predictability, and measure whether customization is actually helping.Noteagent configurationCodexPRPiGiving Pi another go on a separate Linux machine to experiment with workflows, customize Pi extensions and herdr plugins, and see how far I can push a more open agent harness alongside Codex.ProjectPiagent harnesses