Tooling for AI-assisted engineering workflows

Context and problem

Using agents to develop software raises a question that goes beyond generating code: how can work be automated without losing control over what is happening?

A real workflow includes repositories, branches, modified files, tests, CI results, and pending decisions. Without a clear representation of that context, a technically valid change can be difficult to audit or continue. This personal tool emerged as a way to experiment with that problem within my own development process.

My responsibility and constraints

I personally designed and developed the tooling to coordinate agent-assisted tasks around Git workflows, including scenarios with multiple repositories. The purpose is to keep work state, evidence, and human decisions explicit.

Autonomy is deliberately limited. Analyzing a situation and proposing a continuation are different capabilities from having authorization to execute it. The tool remains under active development within my personal engineering environment.

Evidence and contracts between stages

The evidence-first approach requires more than a declaration that a task is complete: verifiable Git state, produced files, tests, or CI results. Agents contribute analysis and assisted work; scripts and deterministic validation allow results to be checked against explicit conditions.

The contract-first design defines what information a stage needs, what result it can produce, and what conditions must be met to proceed. This reduces reliance on informal instructions between agents and scripts, without treating an agent's response as sufficient evidence.

In multi-repo scenarios, it matters to check which repository changed and what work remains pending. A command completing successfully does not, by itself, demonstrate that everything is ready for the next operation. I use testing and harnesses to simulate situations and check behavior reproducibly.

Persistence and reconciliation

Persistence makes it possible to resume work without relying exclusively on an agent's conversational context. That continuity requires reconciling recorded information with the current Git state and available validation.

A previous assertion does not replace observation of the present state. If the work changes, earlier evidence may cease to be valid and need to be checked again. Retaining a result and checking that it is still current are different responsibilities.

Human gates and autonomy limits

Determining the next safe action does not mean executing it automatically. The tooling can analyze state, check conditions, and propose what should happen next; certain transitions require an explicit human decision.

Gates keep sensitive decisions visible. Automated validation does not grant permission to proceed, and a proposal is not equivalent to an action performed. Parts of the workflow can be analyzed and automated, while responsibility for authorizing those decisions remains with the person.

Before proposing how to continue, I check recorded evidence against the observed state. If it is no longer valid, revalidation and reconciliation are needed.

Validation, results, and demonstrated scope

The implementation includes contracts, persistent state, reconciliation, and automated suites for critical behaviors, backed by private tests, harnesses, and CI. Those tests have helped detect repository-boundary problems, insufficient validation, and states considered complete without sufficient evidence.

I use it to support my own development process. That use does not operationally demonstrate every implemented capability: behavior exercised through internal tests has a different scope from what is evidenced in a real workflow.

Some capabilities still await enablement or operational demonstration. Integrating a capability and passing its tests do not justify presenting it as a real operation already performed. The current result is a workflow engineering lab with human control and limited autonomy.

What it demonstrates

• Designing agent-assisted workflows with contracts and verifiable conditions.
• Integrating Git, testing, and CI into evidence assessment and change control.
• Addressing persistence and reconciliation to continue work as state changes.
• Setting boundaries between automation and human intervention using engineering judgment.

Technology and evidence

• Bash
• Git
• CI

Technology and practices: Bash · Git · testing · harnesses · CI · agent integration · contracts · persistence · reconciliation.

This account is backed by private evidence of implementation, testing, and reproducible runs. The public diagram communicates engineering principles and their limits; its conceptual nature does not make it evidence of the operation of every capability.

Privacy note

PRIVATE TOOLING

The portfolio presents the problem, technical principles, and a derived representation. The code and internal implementation remain private.