The .taxonomy File

Taxonomy delivers GPS coordinates in the infospace. Content nobody can locate is content nobody finds. Taxonomy defines the locations on the map the business holds firmly in its hand. Taxonomy is the language for infospace orienteering instruments The .taxonomy file connects the abstract taxonomy to actual content. It declares a taxonomy location using the DBJ Core Taxonomy vocabulary. Not only for code — repositories of documents, images, specifications, any kind of content. ...

Do we have the right set of skills

IMPORTANT One Liner Summary: skill.md is not guaranteed to be used DBJ Observations and Comments Observation: runtime infrastructure is not deployment infrastructure Agreed, so what? In the era of the general lack of experienced engineers that has to be said. Plainly. Observation: Skill is key problem is, it is keeping the whole agent scaffolding non-deterministic It’s not Skill, it’s the mechanism that is supposed to use the Skill. Fuzzy natural-language matching against a description, decided by the model at invocation time rather than part of a fixed dispatch. same mechanism is what makes deferred-tool loading (ToolSearch), subagent selection. Also the ordinary tool choice (Grep vs Read vs Agent) is then non-deterministic too. Skills are just the most visible facet of the LLM non-determinism because they’re named and listed explicitly. But skills are used non deterministically. The classical-software analogue is late binding / reflection-based plugin dispatch Skill mechanism is trading a fixed call graph for runtime flexibility, and paying for it in determinism lacking. Repeating. It is not “Skill” that is the problem, it is that harness resolves most capability binding (skills, tools, subagents, memory recall) via probabilistic matching instead of a deterministic dispatch table And that’s a structural feature of the whole LLM architecture, not a flaw isolated to the Skills. There is no deterministic table dispatch. It is as simple as that IMPORTANT The Message ...

The Danger-Kruger Peak

There’s a ladder. The rungs are labeled “AI Competence.” A novice climbs it, rung by rung, using a critical shortcut: “I didn’t learn, but the AI did.” It works. For a while it works great. The climb is fast, the view improves with every step, and the effort-to-altitude ratio feels like magic. Then the ladder ends. Not because the climber ran out of energy — because the ladder did. That point is the Danger-Kruger Peak: the spot where AI hallucinations start looking exactly like wisdom, because the climber has no competence of their own left to tell the difference. ...

Post-Hype Agents

Post Hype Agents This document defines a pragmatic, engineering-first approach to “Agentic” architectures, aligning them with the rigorous standards of the DBJ Method as established at DBJ.ORG. To move beyond current industry hysteria, we define the “Agent” not as an autonomous entity, but as a Policy-Controlled, Deterministic-Adjacent Task Handler. 1. Core Architectural Principles The Agent is a Consumer: Agents are treated as standard microservices. They pull from event streams (e.g., SQS) and execute strictly defined calls to backend APIs. Semantic Adaptation: The LLM is strictly used as a semantic bridge—translating unstructured input (text, legacy formats) into structured data—not as a substitute for business logic. Determinism First: All logic remains in compiled, testable code. The LLM handles the “intent parsing,” while the DBJ Method dictates the “transactional execution.” 2. Governance and Safety (The “Kill Switch” Model) Following the principles of identity-centric security, an Agent is a first-class identity entity: ...