October 23, 2026 • Software-factory field notes
An engineering agent can keep working without bringing a project closer to delivery. It can write code, pass a test, produce a persuasive update, and still leave the next person unable to answer a basic question: what is actually ready, and what happens next?
That is the problem we are addressing inside Dharma AI itself. We are applying our Cognitive Integrity methodology to the agents building our products: retain the evidence behind a decision, make responsibility explicit, and turn recurring failures into instructions that can be tested and reused.
After four days of this operating approach, Dharma AI cofounder Nikita Annt reports clearer estimates, better visibility into delivery, and renewed progress on projects that had been delayed for months. It gives us a concrete question to test: can the same discipline reliably help the next agent, on the next task, without the founder having to rediscover the same problem?
Where work gets stuck
In a long-running engineering project, the difficult failures often occur between useful pieces of work. An agent finishes an analysis but not the requested outcome. A package passes its own tests but has not been accepted by the application that needs it. A deadline survives in a status update after its prerequisites have changed. A later worker inherits a summary but not the evidence or restrictions behind it.
More parallel agents can amplify these problems unless they share a reliable way to hand work over.
Cognitive Integrity requires the proposed action, supporting evidence, permissions, and reported result to agree. Each handoff carries the requirement it must satisfy and the evidence the next owner can check.
The business objective is simple: more usable work, less repeated investigation, and less time spent reconstructing whether an agent actually finished. We are measuring toward that objective rather than presenting activity counts as savings.
What we changed in our own workflow
We are using Codex and Claude alongside independent review and coordination, rather than asking one agent to produce, approve, and declare success for its own work. The workflow makes five things explicit:
- The outcome. What must become true for this piece of work to be accepted?
- The owner. Which worker is responsible, and who receives the result?
- The evidence. Which artifact, test, or observed effect supports the claim?
- The next update. When will the owner report a result, a revised estimate, or a precise blocker?
- The retained correction. What should a future worker do differently when this failure appears again?
We review the agents’ recorded work for recurring failures. A skill is a reusable set of instructions. When the evidence supports a change, we create a new skill version, test it, and check what happens when the worker uses it on a later task.
In Dharma’s terminology, a Failure Atlas records verified patterns of failure and their supporting evidence at the point where an agent is about to act. It is separate from the proposed fixes. That distinction lets us check both the diagnosis and the correction, rather than assuming a plausible new instruction will solve the problem.
The orchestrator learns too
The learning design includes the coordinating agent, not just the workers writing code. Its daily review asks whether each delivery met the agreed scope, which promises or estimates were missed, what blocked the next owner, and what the actual evidence shows. Relevant failures are retained in the Failure Atlas so the next review starts with the lessons already learned.
A justified correction becomes a versioned skill change: preserve the previous instructions, test the changed behavior independently, then check its application on later work. A day with no justified change should produce a review record, not an invented update.
The coordinating agent’s own daily review produced a change to its accountability skill. We tested and installed the change, then used it on a real report on October 23. The report’s coverage check could not pass until an independent review was attached. Once that review was added, the coverage check passed; unknown event times remained marked as unknown. This shows the revised check being used in real work. It does not measure a productivity gain.
The same discipline applies to each project worker's skills. Daily review examines delivery across the team; a separate policy can examine batches of 100 completed trajectories, the recorded steps of an agent’s work. The two cadences complement one another. Neither a calendar entry nor a newly generated skill is the result: the result to measure is a better subsequent delivery.
A lesson for the next dependency update
A recent engineering correction addresses a practical release risk: updating a software dependency can fix one problem while breaking what an already-published package promises its users.
The revised instructions tell the worker to check the exact package already published and what its users rely on, not only the dependency declaration being edited. The original engineering worker received the specific correction and explicitly accepted it for relevant future work. The supporting package checks were preserved with the handoff.
The worker has received and accepted the correction. On its next relevant dependency update, we can check whether it follows the instructions and preserves the package’s behavior. That later task, rather than the acknowledgment alone, will show whether the lesson helped.
How the improvement model works
We compare the behavior a skill is meant to change. We retain a baseline, a candidate revision, the task evidence, and an unchanged acceptance check. Misses and regressions stay in the comparison.
In one recorded forecasting example, a task completed in 166 seconds against a forecast range of 600–1,500 seconds. Finishing sooner is welcome, but the estimate still missed its declared range. It should not be counted as evidence that forecasting became accurate.
In another review, a mismatch in the recorded source was caught and corrected without overwriting the original evidence. The next reviewer can see both the problem and the repair.
Every skill update should face that same discipline: retain the prior version, compare relevant tasks under the same acceptance criteria, and record regressions as well as successes. Customers benefit when the next delivery is more dependable.
From our internal workflow to a customer product
Customers should not need to replace their existing agents to benefit from this approach. Agent Fabric is the connection layer for their agents and tools. Plugins and an installed command-line tool, the CLI, connect their work to the same review and learning process.
We are developing three execution paths: an independent worker beside the agent on the customer's machine; Indra-led evaluation coordinated with a local agent; and a separate managed execution layer. Indra is Dharma’s evaluation and learning technology, using Gemini with Dharma instructions in the architecture described here. Across these paths, the intended process is to collect permitted evidence, evaluate completed work, test a proposed correction, and return an authorized skill to the appropriate agent.
The CLI is intended to collect permitted work records without relying on the agent to remember to send them. Across all three paths, a correction must be tested before it reaches the worker, then checked in later use.
How this connects to our earlier studies
Our internal software-factory work extends a question we have been testing in other settings: can a recorded failure become a useful, verifiable change in behavior?
- From agent failure to verified improvement: with the same underlying model, the baseline passed 3 of 30 source tasks, and a reviewed correction passed 30 of 30 separate held-out tasks. This disclosed synthetic evaluation tested evidence-backed decisions and governed remediation. The source and held-out sets differ, so these counts are not a paired estimate of improvement on the same tasks.
- Teaching an AI appraisal system to learn from expert corrections: on 100 labeled appraisals, the approach using the same model with the skill raised the provisional operational price score from 70.18 to 75.79, a 5.61 percentage-point learning-set gain. Usable prices rose from 94 to 100; 30 items regressed. The labels were used to build and select the skill, and the local scorer was provisional. The result demonstrates candidate improvement on that learning set; separate customer blind pricing scores are needed to establish generalization.
- From agent output to verified progress includes our BFCL-based benchmark work. Those controlled studies did not establish an advantage from the Atlas over matched alternatives. We kept failed promotion checks and regressions in the record instead of treating skill delivery as proof of improvement.
The new contribution here is operational experience: applying that discipline to our own long-lived engineering work, then checking whether corrections survive the next handoff.
What we measure next
For each new skill version, we will compare later work with the previous version under the same acceptance criteria. We will record which failures were repaired, which remained, and which new problems appeared.
That is how we intend to measure Cognitive Integrity’s value to an engineering team: whether its agents deliver more dependable work with less repeated investigation. Our four-day experience gives us examples to test, not a substitute for those comparisons.