Duke's Tech Knowledge Database Living Handbook · v14 · Compiled 24 September 2026

AI Agentic Platforms & Workplace Automation

Core Principles

  • Autonomous, goal-oriented execution is the dominant new product direction as of mid-2026, appearing under different names across vendors rather than being any single company's unique feature (DK-10, DK-13, DK-14).
  • "Package this workflow into a reusable Skill" has emerged as a convergent design pattern across major AI platforms, not a single vendor's feature (DK-10, DK-11, DK-13, DK-14, DK-15). NEW (v10) — this pattern now extends beyond Claude/ChatGPT into cross-tool skill sharing: Matt Wolfe's roundup of "AI skills worth installing" treats SKILL.md files as a genre spanning Claude Code, Codex, Cowork, OpenClaw, and Hermes alike, distributed simply by pasting a GitHub URL into a chat (DK-69).
  • Local file and computer access is what separates a "cloud assistant" from a "workplace agent" (DK-10).
  • Automatic fallback behavior — switching to browser automation when a direct integration fails — is treated as a sign of robustness, not a workaround to be embarrassed about (DK-10).
  • Sharing and downloading third-party reusable workflows introduces a supply-chain-style security question (DK-11).
  • A recommended overall AI strategy is converging across independent sources: pick one primary ecosystem and go deep, rather than switching shallowly between many tools (DK-15).
  • Sharing AI-built work is evolving from static exports toward live, hosted, continuously-synced interactive applications (DK-16). NEW (v10) — a mobile-monitoring variant of this pattern has also emerged: rather than hosting a static or live web deliverable, agentic tools are increasingly designed to keep running on a fixed machine while being checked in on and steered remotely from a phone.
  • Multiple independent sources now converge on the same clarifying-questions-before-starting technique under different names (DK-15, DK-18, DK-21, DK-31).
  • The "treat AI as a teammate, not a tool" framing recurs across sources as the dividing line between high- and low-value AI usage (DK-15, DK-21, DK-31).
  • A significant counter-perspective exists to the optimistic agentic-platform narrative: because multi-step agent workflows compound per-step error rates, even a high individual-step accuracy can produce a surprisingly low overall task-completion rate (DK-23).
  • A file-based configuration architecture is emerging as a detailed pattern for structuring persistent AI context in agentic workspaces (DK-32).
  • AI systems are increasingly reported to assist in their own development pipeline, described as an early, human-supervised feedback loop rather than full autonomous recursive self-improvement (DK-40).
  • NEW (v10) — Permission and credential access, not raw capability, is repeatedly identified as the actual ceiling on what agents can be trusted to do — reinforced this version by a concrete product answer rather than only being named as an open problem: letting an agent use credentials without ever seeing them.
  • NEW (v10) — Default-on autonomy (an agent proceeding through multi-step work without per-step confirmation) is moving from an opt-in power-user setting toward a default state for major agentic coding tools, justified by labs citing measured harmful-action catch rates rather than simply user convenience.
  • NEW (v10) — "Teach by demonstration once, replay indefinitely" is emerging as a third skill-creation method alongside the two already documented in this Handbook (conversational package-into-a-skill, and hand-authored SKILL.md files): recording a task once and having the agent generalize the recording into a reusable, human-readable, editable skill.
  • NEW (v11) — Discovery has become the highest-value capability in the skills ecosystem by a wide margin, which is itself evidence that the catalogue has outgrown any manual way of navigating it. On the official Claude Skills leaderboard the top entry is not a skill that does a job but one that finds skills — Vercel Labs' Find Skills at a reported 2.9 million installs, roughly 3.5 times the next entry (DK-82). This extends the SKILL.md-as-portable-genre pattern already recorded (DK-69) into its logical consequence: a catalogue large enough to need a search engine.
  • NEW (v11) — The most-installed skills are overwhelmingly about process discipline rather than new capability: interrogate the plan before building it, define what correct looks like before producing anything, hand context between sessions cleanly, and decide what to work on first. This reinforces from install data what this Handbook already records from advice content (DK-15, DK-21, DK-31) — that the constraint on useful AI work is the discipline around it rather than the model (DK-82).
  • NEW (v12) — Agents have so far been built for one person working alone, and most work in an organisation is not done that way. OpenClaw 2.0's significant change is multiplayer: a shared agent session two people can both open, where either can add context or take over when the agent is waiting on input (DK-98). The concrete consequence is the best line in the source — handing over a half-finished project normally means assembling everything in your head into a document, whereas here "the session itself became the handoff document".
  • NEW (v12) — The barrier to adoption at the top of the industry is habit, not capability, and the evidence is unusually direct. Sam Altman on his own behaviour: he has had Codex for months and still clicks between messaging apps, still scrolls email, still keeps a to-do list the old way. "By revealed preference, I have a better way to do it now and I still do it the old way... we build intellectual mind muscle memory" (DK-100). For any reader wondering why their organisation has not changed despite everyone agreeing it should, that is the answer from the person with the least excuse.
  • NEW (v12) — Agentic work climbs a ladder that chat work does not: generation, then synthesis, then execution inside existing systems, then maintenance of those systems over time (DK-100). Chat sits on the bottom rungs. The fastest growth in agentic use is now outside software and engineering, which OpenAI attributes to its own model improvements and the source disputes — arguing users worked out the patterns themselves.
  • NEW (v14) — The "lethal trifecta" is the most useful security framework this Handbook has recorded for agents, because it converts a vague anxiety into three conditions that can be checked against any deployment. Serious exposure to prompt injection requires all three together: private data access (the agent can reach email, calendar or similar); untrusted content (any input can arrive that did not come from the user — an incoming email, a web page — which may carry instructions); and an exfiltration vector (some way to send data out, such as sending a message or posting to an endpoint). Remove any one and the risk falls substantially. The honest conclusion the source reaches is that a useful personal assistant has all three by default and it is "really hard to make a useful second brain without being exposed" — so the discipline is to minimise each pillar deliberately and know which you have granted, not to claim the problem away (DK-126).
  • NEW (v14) — Skills and plugins are different security objects and the distinction has a real consequence. A skill constrains a model that remains in charge; installing a plugin "is like installing software on your computer" — plugins can carry scripts and executable code and are granted access to data, code and secret keys. The practical advice that follows is to install plugins only from a first-party source (DK-127). Read alongside the emergence of scanning tooling for agent extensions — NVIDIA's SkillSpector checks skills before installation for hidden instructions, unsafe access requests and data-leak paths, returning a risk rating (DK-122) — the supply chain for agent extensions has become a security surface in its own right, which is a genuine change from the v10 position that treated skill sharing mainly as distribution.
  • NEW (v14) — Two sources reach opposite conclusions about agent tool security by reasoning from different things, and the disagreement is worth recording rather than resolving. One argues the major tools are "very, very secure because they're built by these massive companies that have a lot on the line" — an argument about vendor incentives rather than about the threat — while offering sound practical advice underneath it: scope what the agent can reach, prefer read-only on important systems, ensure the worst case is survivable (DK-131). The other reasons from the threat model and concludes you must build your own precisely because a large third-party codebase means "you don't have understanding of how the lethal trifecta is really affecting you" (DK-126). This Handbook's position is that the advice converges even where the reasoning does not, and that an argument from vendor incentives is the weaker of the two.
  • NEW (v14) — Memory in agent systems works by promotion, not accumulation, and this is a structural answer to the context problem that does not depend on any model's context size. The working pattern: append every conversation to a long raw daily log; once a day have a scheduled process read that log and promote what is worth keeping — key decisions, lessons learned, important facts — into a concise file that is always loaded; and because promotion is lossy by design, separately index the full logs so the agent can search back for detail that was never important enough to promote (DK-126). The maintenance rules reported alongside it: keep the always-loaded file to roughly 200 lines, and instruct the agent to save only substantial corrections (DK-131).
  • NEW (v14) — Agent memory is explicit where chat memory is invisible, and the difference is a control surface rather than a deficiency. Chat products save memories automatically to a store the user cannot see or control; agents remember only what is constructed for them. The argued benefit is avoiding cross-contamination — automatic memory pulls context from unrelated conversations into work where it does not belong. The failure mode when memory is absent is demonstrated rather than asserted: tell the agent a preference, watch it acknowledge, open a new session and find it gone. The reason this frustrates people is that you correct the agent, it agrees, and the next day it repeats the mistake — it looks broken when it is simply not writing anything down (DK-131).
  • NEW (v14) — The vocabulary has settled and it is worth stating plainly, because the terms are now used consistently across independent sources. A chat model is question to answer; an agent is goal to result. The agent loop is observe, think, act, repeating — and what makes it useful is that completion is decided by parameters set in the original prompt, so an instruction to compile ten sources and produce a report gives the loop its own stopping condition. An agent comprises four things: the model as the brain, the loop, the connected tools, and the context. The HARNESS is the platform that runs the loop, and the popular products are all harnesses — the analogy offered is learning to drive rather than learning a particular car (DK-131, DK-122). That distinction explains why the same model behaves differently in different products, which is a vocabulary gain the Handbook has lacked.
  • NEW (v14) — Skill packs level models rather than improving them, which is a useful test to apply to any claim that a tool makes an AI better. The argument, credited to a commenter and endorsed by the presenters: a capable model already knows how to do test-driven development, so a workflow pack adds little; a smaller local or open-weight model needs to be told the practice exists and walked through it, so the pack is far more impactful there (DK-127). The corollary is that the value of a skill library is inversely related to the capability of the model reading it.
  • NEW (v14) — The hard problem has moved from making one agent work to stopping several colliding, and the tooling has followed. The failure is specific: agents pointed at a single working copy edit the same files, collide over who changed what, and break features. The mechanism adopted is a separate working copy per agent — a git worktree — merged back afterwards (DK-127, DK-128). Around that, the practical problems people are now solving are project-centred workspaces that open a project and then pick an agent rather than the reverse, dashboards showing which of the running sessions is stuck, and spend tracking across several providers for people who "don't find out until you run out of cash" (DK-127). Note the convergence on the terminal rather than the editor, on the stated grounds that the terminal gets features first and "probably half the features almost never make it to the extension anyway" (DK-128).

Key Facts & Examples

  • ChatGPT Work: goal-oriented autonomous execution; desktop app can read/organize/edit local files with permission (DK-10).
  • Claude Skills are described as reusable "recipe cards" — Markdown files that store instructions/context for recurring tasks (DK-11).
  • A beginner-focused Claude Code walkthrough showed Plan Mode, /init context files, MCP Connectors, autonomous build-test-fix loops (DK-14).
  • Recommended general-purpose prompting framework ("ICC"): Instructions, Context, Constraints, plus optional Examples (DK-15).
  • Claude Code Artifacts: publishing anything Claude Code builds as a live, hosted, interactive web app with a shareable URL (DK-16).
  • A detailed file-based Cowork/Code architecture: root claude.md for universal rules (200–250 line target), a separate memory.md for current facts, an archive.md for outdated information (DK-32).
  • On agent reliability: a 90% per-step accuracy rate compounds across a 10–50 step workflow to produce a much lower overall task-completion rate (DK-23).
  • NEW (v10) — Anthropic and 1Password launched "1Password for Claude," letting Claude sign into sites and use one-time passcodes without the credentials ever entering its context. The flow: Claude hits a login page, 1Password shows the user which credential it wants and why, the user approves with Touch ID, and 1Password fills the login and any MFA code through a secure channel; the rest of the vault stays locked, access ends with the task, and a failed form submission is wiped before control returns. A Wall Street Journal reporter tested it on a retirement fund and it worked. Limits as reported: Mac-only, requires the 1Password desktop app and extension plus Claude desktop and Claude in Chrome, logins and OTPs only (not broader form-filling), and a paid Claude plan plus a 1Password subscription (DK-75).
  • NEW (v10) — Anthropic is switching Claude Code's "auto mode" on by default for Pro, Max, and Team users, letting it work through more steps without asking permission each time. Anthropic reports that testing with 1,053 paid testers found auto mode caught 89% of harmful actions versus 13.6% under human review — partly attributed to users approving 97% of permission prompts anyway, meaning human review was adding friction without proportionate safety benefit. New guardrails introduced alongside the change include prompt-injection screening and customisable hard deny rules against data exfiltration (DK-81).
  • NEW (v10) — OpenAI rolled out Record & Replay for Codex: a user hits record, performs a task once on their Mac, and Codex converts what it observed into a reusable skill callable later. Three things reportedly distinguish it from older RPA tools like UiPath: it captures intent rather than pixel coordinates, so it does not break when an interface changes; the generated SKILL.md file is human-readable and editable rather than a black-box recording; and it works across browser use, computer use, and connected plugins (Slack, Gmail, Notion). Caveats: macOS only at launch, unavailable in the EU/UK/Switzerland, and requires an active ChatGPT subscription with Computer Use enabled (DK-68).
  • NEW (v10) — Matt Wolfe's "AI skills worth installing" roundup treats SKILL.md files as a portable, cross-vendor genre: named examples include GStack (Garry Tan's 23-specialist bundle simulating a virtual engineering team — a CEO role that pressure-tests ideas, a designer that catches AI slop, a security officer running OWASP audits, a release engineer that ships the PR), Stop Slop (strips AI writing tells out of prose), Graphify (turns a codebase or second brain into a queryable knowledge graph used as agent memory, with a claimed 71× token reduction per session on large projects), and Last 30 Days (real-time sentiment research across Reddit, X, YouTube, Hacker News, and Polymarket) (DK-69).
  • NEW (v10) — OpenAI shipped Codex on mobile (preview, iOS/Android, all plans including Free): the phone does not run the code itself, it acts as a remote control while Codex keeps running on the user's Mac/laptop/devbox. Demonstrated setup took about a minute (update Codex, scan a QR code, connect); the phone can immediately pull up existing chat sessions and inspect/read files directly off the connected machine's hard drive, running live on both devices at once (DK-60). This extends this Handbook's "agent runs while you live your life" pattern into a genuinely working, demonstrated remote-monitoring workflow, distinct from the web-hosted Artifacts sharing pattern already documented (DK-16).
  • NEW (v10) — OpenAI's personal finance integration in ChatGPT connects user accounts through Plaid across 12,000+ institutions, giving a dashboard of spending, investments, and cash flow grounded in the user's actual numbers. Independent commentary raised a specific incentive-conflict concern: this is the same company reported to be testing ads inside ChatGPT, and while OpenAI states ads will not influence answers and advertisers will not receive user data, commentary treats that as a significant amount of trust to extend for sensitive personal-finance use cases (DK-62). This sits adjacent to, but is distinct from, this Handbook's existing agentic-permission-boundary material — it's a data-exposure trust question rather than an action-permission one.
  • NEW (v11) — The official Claude Skills leaderboard ranks all published skills by install count, and a walkthrough of its top twelve reports: Find Skills (Vercel Labs) at 2.9 million; Grill Me at 831,000, which makes Claude interrogate a plan before building it and, demonstrated on a SaaS idea, returned eight questions covering who pays, the wedge into a crowded market, proof of demand and an explicit kill switch; Anthropic's Front End Design at 767,200, whose stated purpose is stopping generated interfaces converging on the same fonts, gradients and layouts; Improve Codebase Architecture at 682,000; TDD at just under 626,000; Handoff at 569,500, which writes a compact Markdown file carrying state, decisions and next steps out of an exhausted session; Triage at 567,500; and Lark Doc at 560,000. Six of the top twelve are by a single independent author, Matt Pocock — a concentration worth noting in a catalogue of 85,000. IMPORTANT CAVEAT FROM THE SOURCE ITSELF: the video's countdown does not stay internally consistent between ranks two and four, so the install figures are usable but the rank positions in that range are not (DK-82).
  • NEW (v11) — Handoff's stated purpose is worth recording alongside this Handbook's file-based-context material (DK-32): it addresses what the presenter calls "context rot", where long sessions become forgetful, by packaging the state that matters into a file a fresh session can resume from. This is the same problem the claude.md / memory.md / archive.md architecture already documented solves by convention, approached instead as an on-demand action (DK-82).
  • NEW (v12) — OpenClaw 2.0 is a rewrite rather than an update: 933 contributors across 16,000 pull requests covering installation, messaging, memory, skills, automations, browsers, plugins and security, with the emphasis on deferring configuration into conversation with the agent (DK-98). It did not land cleanly — Alex Finn, who built a following on the original, reported that updating immediately broke it and that "70% plus of the time I update OpenClaw, it breaks it", calling it the most frustrating release of the year. A useful corrective to how this Handbook records agent capability: the tools break on update often enough that an enthusiast says so publicly.
  • NEW (v12) — The multiplayer questions are explicitly unresolved by the people building it — ownership, authority and access — and the maintainers say so: "This is still early, and we're treating it that way" (DK-98). Nous Research shipped a comparable step the same day in Hermes "Pantheon" 0.21.0, including bot-to-bot direct messaging between agents.
  • NEW (v12) — What Astra's computer-use capability looks like in practice, from two detailed reviews rather than benchmarks: one reviewer describes herself as "hands off my computer all the time now", managing complex web interfaces and automating CRM lead routing; another concludes that pretty much any stable workflow done on a computer can now be at least partly done by AI (DK-99). The launch video — three minutes of people pacing a room talking to a laptop while it works, one task in the foreground and another in the background — passed 132 million views in four days, and the interaction pattern is the pitch.
  • NEW (v12) — Reported costs for agentic 3D and game-building work, recorded because everyone assumed it would be ruinous: a one-shot browser game at "under $30"; another built in 45 minutes for a couple of per cent of a quota; a Sonic clone in 53 minutes using 4% of weekly usage at maximum effort, or 25 minutes and 1% on medium (DK-99).
  • NEW (v13) — Meta's Muse is the week's significant agent launch and the security architecture is the part worth recording: each instance runs in its own isolated virtual machine, a separate system called Sentinel checks every action before anything leaves it, credentials go into secure storage the agent cannot see, per-app access is user-chosen, and training on interactions can be opted out of (DK-104, DK-109). These are Meta's claims, not tested.
  • NEW (v13) — The hands-on verdict on Muse from a tester who has used the alternatives: "probably the easiest agent I've ever used" and the simplest onboarding he has had, against OpenClaw, ChatGPT Work and Claude Cowork — with the trade-off being integrations, where the others connect to far more (DK-104). Reported as the No. 2 app in the US.
  • NEW (v13) — The most instructive detail from that test, and it is about connected accounts rather than about Muse: before being given anything, it inferred location, marital status and professional focus from connected Facebook and Instagram, then working rhythm from calendar and inbox. Presented as convenience; it is the clearest available demonstration of what connecting an agent to existing accounts actually surfaces (DK-104).
  • NEW (v13) — Adoption friction for personal agents is now trust rather than capability. From A16Z's Olivia Moore on Muse: "I was more reluctant to press the connect email button on Muse than on 10+ startup agent products I've tried" — distribution advantage cutting both ways (DK-109).
  • NEW (v13) — Cognition's stated thesis on staying independent is a position on the same question from the supply side: being able to choose and combine the models best suited to the work rather than tying customers to one provider, which the source reads as informed by watching OpenAI cut off access to Cursor customers after SpaceX's acquisition (DK-109).
  • NEW (v14) — Permission asymmetries as a concrete pattern, reached independently by two practitioners and worth copying directly. One grants his system read-only access to messaging with no ability to post, the ability to create email drafts but not to send them, task management in named projects only, and calendar reading without calendar management — starting read-only and adding deliberately (DK-126). The other expanded scope while leaving authority untouched and still reads every outgoing email (DK-130). Both describe the same shape: the agent may prepare anything and commit nothing.
  • NEW (v14) — Realistic timescales for building an agent workforce, which is the useful counterweight to the enthusiasm in this category. A baseline can be set up "in under 3 hours" from a single interview-style prompt; getting it to what the practitioner calls the 90%-plus level took MONTHS, with early failures described concretely — an agent reporting a booking confirmed when negotiation was still under way over a channel it could not see (DK-130). A second source gives the same shape from the other end: build phase by phase starting with the memory foundation, and do not have a coding agent build the whole system at once because it will not work and you lose control of what is being built (DK-126).
  • NEW (v14) — Model tiering inside an agent workforce, stated as practice rather than theory: "not everything needs Opus. All of my sub-agents are Haiku and Sonnet" (DK-130). Capability matched to task rather than maximised by default — the specific case underneath the new operating principle on this.
  • NEW (v14) — A monitoring role pointed inward at the system rather than at the work, which is the most transferable role design in this batch. One agent's only job is watching the other agents work and recording where friction occurs and who lacks access to what — surfacing patterns such as one agent's output being corrected repeatedly for want of a permission (DK-130). The same practitioner maintains a dictated daily diary of everything not already captured in meetings, emails or messages, on the reasoning that context the agents cannot see is context that makes their output wrong.
  • NEW (v14) — Agents as watchdogs over things already tracked is named as a high-value use case that almost nobody is exploiting: catching duplicated work, calendar conflicts, or points of disagreement across meetings. The distinction drawn is against dashboards, called "dumb" — what is wanted is anomaly detection and a recommended action rather than a number (DK-130).
  • NEW (v14) — Skills are standard operating procedures for AI — "once you explain something once, you never have to explain it ever again" — and the distinction from memory is operational: one-off formatting preferences for a particular deliverable belong in a skill rather than clogging the memory file. Two creation methods are reported: feed in an existing document such as a course transcript and have the harness's own skill-creator build one, or perform the process manually once and ask it to package up what was just done. The second is the more general technique (DK-131). One skills pack reported at 95,000 stars is presented as a single ordered workflow rather than a collection — spec, plan, code, test, review, ship — with the observation that most people start at "code" and skip both ends, and that test and review are the most commonly skipped (DK-127).
  • NEW (v14) — A worked before-and-after on skill packaging: an advertising analysis process described as taking three to four hours manually was performed once with the agent over about two hours, then packaged as a skill; a later run is reported scraping roughly 220 competitor advertisements with landing-page screenshots and a written breakdown (DK-131). Self-reported, single instance, no verification of output quality — but it is the most concrete process-to-artefact account the Handbook holds.
  • NEW (v14) — Scoping matters for cost, not tidiness. Skills, context files and tool connections can each be global or scoped to one project, and the stated reason to scope is that a narrow skill loaded everywhere "plugs up the context" where it is not needed (DK-131). Related advice from the same period: delete instructions written for older models from a project's context file, because the current model reads them and spends effort fixing problems it no longer has — the test being to remove one instruction, re-run the same task, and treat it as dead weight if nothing changes (DK-124).
  • NEW (v14) — An enterprise vendor shipping skills so that somebody else's coding agent is competent on its platform, which is a different commercial posture from building its own assistant. UiPath ships instruction files installed into the coding agent that teach it the platform's patterns, project structures and conventions, loading automatically when the agent is opened inside a project of that type — so the output is not generic code but a project the platform can run, evaluate and deploy (DK-125). The entry is a sponsored tutorial and its verdict carries no weight; the pattern does. If this becomes the norm, the competitive question shifts from which vendor has the best assistant to whose conventions the agents know, which is a distribution question rather than a model-quality one.
  • NEW (v14) — Tools built around a model's current gaps expire as the gaps close, and a presenter says so about a repository trending that week: a desktop-control tool adds little because the models can already read and write files anywhere, use the terminal and find things themselves — "eight months ago I would have been blown away, but now I think the built-in tools are doing this" (DK-128). Worth carrying as a discount to apply to any roundup's implied durability, including the ones in this Handbook.
  • NEW (v14) — Announced-but-not-available has become a pattern worth naming. A creator on a $200-a-month top-tier plan documents three launches in one week presented as available that he could not use: a product merger rolling out "over coming weeks", a redesigned projects feature announced as "now available in beta" but limited to selected subscribers meeting several conditions with a waitlist for everyone else, and an assistant upgrade announced as available that day for which he was waitlisted while running the beta operating system. His argument is that the announcement should come when the thing ships (DK-134). Relevant to this Handbook's sourcing: a feature described in a launch post may not have been used by anyone outside the company, including the person reporting it.
  • NEW (v14) — A practitioner finding about general versus specialised models that no benchmark would surface. Robinhood reports that general models often simply refuse to trade — asked to deploy a strategy they respond that they do not feel like trading right now — and the stated explanation is that trading traces are absent from their training data so guardrails catch it, rather than any risk assessment having been made. The company expects specialised models, fine-tuned open weights or in-house pre-trains, to beat general models here, and describes experiencing directly what had been a theoretical argument (DK-119). The surrounding product detail: a segregated account funded deliberately with typically about US$100, started equities-only with no leverage or margin, currently driven from a coding agent, which the CEO concedes is too complicated for the general public. Diamandis states over 100,000 accounts are running agents; a company-adjacent figure.
  • NEW (v14) — Context engineering has displaced prompt engineering as the stated skill: with enough business context loaded into files the agent always reads, the prompt can be "stupidly simple" and still produce a usable result. The demonstration supports it narrowly — the same four-word request produced a generic reply before the context file and a specific one after (DK-131). The context file goes by a different filename in each harness and is the same concept, equivalent to the custom-instructions field in chat products; files sitting in a project are not loaded unless something tells the agent to read them.
  • NEW (v14) — Running exploratory work in a disposable side session is a pattern worth keeping independently of the tool implementing it: the main conversation receives only the vetted answer rather than the fifteen files opened, the tool calls that failed and the two wrong turns taken to reach it, so the main context holds the work rather than the searching (DK-127). A related warning on unattended iteration: a model can critique its own output and loop until it meets a quality bar, but a loop set on a task the model is bad at "can end up spending all day" consuming tokens, so cap the iterations (DK-123).
  • NEW (v14) — Reported behavioural quirks with prompt-level fixes, recorded because they are the kind of friction that reads as the model being broken. Current models may behave as though supervised and stop mid-task to ask permission for steps the original request already covered — the fix offered is to state that nobody is watching and to proceed with anything reversible. And they do more than asked: one user reports requesting a single feature and finding his test files rewritten unprompted, and now names what must stay untouched and asks for other problems to be reported rather than fixed (DK-124). The source is careful not to oversell the first fix, noting it does not cure drift on long sessions and that the model "still writes code that runs fine while quietly doing the wrong thing".
  • NEW (v14) — A cost mechanism specific enough to act on: left alone a model will regenerate an entire file when the change is four lines, and every one of those output tokens is billed. Instructing it to edit only the part that needs editing is invisible on one small script and "turns into real money" on a project of a few hundred files (DK-124).

Source Articles: DK-10, DK-11, DK-13, DK-14, DK-15, DK-16, DK-17, DK-18, DK-21, DK-23, DK-31, DK-32, DK-40, DK-45, DK-47, DK-59, DK-60, DK-62, DK-68, DK-69, DK-75, DK-81, DK-82, DK-98, DK-99, DK-100, DK-104, DK-109, DK-119, DK-122, DK-123, DK-124, DK-125, DK-126, DK-127, DK-128, DK-130, DK-131, DK-134

Version 14, compiled 24 September 2026. 135 source entries (DK-2 – DK-136). Claims are recorded as their sources framed them; figures described as claimed or reported are not independently verified.