An agent can produce a convincing explanation while leaving the requested change unfinished. A handoff can lose the requirement that mattered. A reviewer can approve a tidy artifact that has never been integrated. When something fails, the next attempt can repeat the same mistake.

For engineering leads building agent-assisted products, that is the practical problem: not getting more output, but knowing which output became verified progress, and which lesson will survive the next handoff.

We are building Dharma AI's software factory around that distinction, with DAI.app as an ongoing internal application. This is an account of the boundaries we are learning to enforce, not a claim that the factory has autonomously delivered the whole product or proved a productivity gain.

Three layers, three different jobs

It helps to separate coordination, workflow and learning. Calling all three an autonomous agent hides the most important questions.

Agent Fabric is the coordination layer. Its interfaces cover agent identity, organization policy, bounded tasks, evidence and skill delivery. Those mechanisms are intended to make responsibilities and handoffs explicit: which agent is acting, for whom, on what scope, and under which conditions. A configured interface or a successful delivery receipt does not establish that the requested work succeeded.

The software factory is the development workflow. The intended sequence is planning, bounded work, independent review, integration and the next authorized use. Each transition needs its own acceptance check. We have exercised bounded pieces of that workflow; the evidence described here does not establish a complete Fabric-dispatched development-to-production chain for DAI.app.

Evaluated learning is a separate loop. Observations become candidate corrections, candidates are validated against unchanged requirements, and only supported corrections should reach an authorized future task. Generating a rule is not the same as learning something useful. Installing it is not the same as using it. Using it is not the same as improving the outcome.

Our architectural hypothesis is that these layers can connect a failure to a traceable change in behavior. Whether that connection produces a benefit remains something to measure, not something the architecture guarantees.

A bounded example: review the artifact, not the promise

One related coordination exercise assigned two small offline components with separate artifacts and acceptance checks. The work included an explicit package boundary, a consumer-facing acceptance format and independent review. Added regression cases demonstrated defects before the repairs were accepted; a packaging rework remained in the record.

The useful result was limited but concrete: reviewed offline artifacts, with checks tied to the component requirements and failed attempts preserved. The exercise did not establish runtime integration, production delivery or a measured reduction in development time. It was manual/native coordination, not evidence of an autonomous Fabric dispatch.

For a team, the intended benefit of this discipline is straightforward. A later owner should be able to distinguish a proposed change from a reviewed package, and a reviewed package from an integrated result. That can make a handoff more inspectable without asking the recipient to trust the previous agent's summary. We have not measured the time savings of doing so.

DAI.app is where we continue to apply these questions to our own development. We are not presenting its ongoing work as proof of end-to-end factory autonomy. Product acceptance still needs evidence from the actual product, not a borrowed benchmark score or a different component's passing checks.

The benchmark lesson we kept

Our completed BFCL-based studies did not establish an Atlas advantage over matched alternatives. A later development continuation also failed its promotion criteria, retained unavailable attempts and a regression, and demonstrated no verified executable correction intervention. We preserve those results rather than turn a favorable development checkpoint into a general improvement claim.

That record sharpens the question we need to answer: did a retained correction change a relevant action, and did the same acceptance check then pass? Ordinary memory must receive matched substantive evidence and allowances. Missing results and regressions must remain visible. Different cohorts, extra computation and source-test success cannot substitute for that comparison.

BFCL's published multi-turn methodology evaluates actual API-system state. Our controlled subsets are not a leaderboard submission or evidence of better coding performance. Native skill delivery and rollback are operational evidence, separate from performance improvement.

A checklist for one real workflow

Before expanding an agent-assisted workflow, ask:

  • Is the requested outcome explicit, including the target and observable effect?
  • Can the next owner inspect the actual artifact and evidence, rather than only an acknowledgment?
  • Does independent review test the same requirement that motivated the work?
  • Are integration and current usability checked separately from package creation?
  • If a correction is retained, can you trace its origin, applicability, delivery and subsequent use?
  • Are regressions, unknowns and failed attempts preserved alongside successes?

These questions do not promise autonomy. They make it possible to tell what the system actually accomplished and where a human decision or another check is still needed.

For teams exploring this approach, start with one bounded workflow and one observable acceptance check. Discuss one bounded workflow with Dharma AI, without assuming a wider deployment is ready. The goal is a small, inspectable learning loop: failure, retained correction, observed intervention, unchanged acceptance.