Building with AI agents while keeping human authority

October 5, 2026 · Kishore Babu Gutta

As a solo founder building Engineering Runtime, I use AI for research, design, implementation and review.

The challenge is deciding which findings deserve work, keeping decisions intact across sessions, and knowing what has actually been proved.

A useful conversation can produce several ideas. A code review can uncover a genuine defect. A new provider feature can change an assumption. Without a process, each becomes another disconnected task.

I have been building a workflow that gives those inputs a place to go.

Agents can discover, propose, implement and verify. The founder retains authority over product direction, release scope and publication.

This article describes that development workflow. It is not a claim that Engineering Runtime itself orchestrates these agents or enforces all of these repository rules.

As of this writing, v0.12.0 is the first release intended to exercise the newly connected process from scope reconciliation through post-release issue closure. The rules are recorded; the complete cycle still needs to be demonstrated.

Start with evidence feeders

Useful work comes from more than a feature list.

Feeder	Example	First durable destination
Vision	A customer problem or architectural decision	Founder notes or Knowledge
Research and ecosystem	A protocol change, provider limitation or substantive paper	Knowledge research report
Code review	A reproducible defect or missing contract check	Runtime issue; broader learning in Knowledge
Usage	Dogfooding failure or user feedback	Issue with reproduction, or a product-learning record
Release evidence	Qualification failure, compatibility gap or recorded limitation	Release evidence, then an issue or candidate
Adoption	Confusing help, onboarding friction or a gap discovered while making a demo	Issue, Knowledge or Founder notes according to the finding

These destinations separate evidence from a commitment to build something.

An interesting paper does not automatically become a feature. An issue does not automatically join the next release.

Scheduled research feeds Knowledge

I use scheduled ChatGPT research to collect developments relevant to Engineering Runtime: provider changes, agent interfaces, execution safety, standards and architecture research.

The maintained Knowledge workflow calls for dated reports with a short list of substantial findings. Each finding should explain its source, what changed, why it matters to this product, and what question or experiment follows.

It can also say “no action.”

That is useful. A research agent should help filter the world, not fill a roadmap with everything it discovers.

When I ask for Backlog preparation, the planning agent reads the relevant reports alongside existing decisions and current code. Only findings with a concrete product consequence become candidates.

The schedule is a discovery trigger. It is not authority to change architecture or start implementation.

Daily themed code reviews feed issues and learning

I also use scheduled Claude Code routines to inspect the codebase through different themes across the week.

The theme gives a run a bounded question rather than asking it to improve everything at once. The exact themes belong in the maintained routine configuration; they can change as the product changes.

The useful output depends on the finding:

• A reproducible defect becomes an issue with the inspected baseline, expected behavior, observed behavior and evidence.
• A broader architectural lesson belongs in Knowledge, linked back to the source finding.
• A bounded fix may become a PR when the routine's own authorization permits it and the change can be proved.
• An unsupported suspicion or repeated finding does not deserve another issue merely to show activity.

A routine reviewing code and a bot reviewing an open PR are separate workflows. Disabling one should not be described as disabling all review.

I use ChatGPT and Claude in this setup, but the roles are replaceable. The process depends on durable records and explicit permissions, not a mandatory model vendor.

Give each kind of record a clear job

I organize the work into a few repositories. A smaller project could use folders in one repository.

Area	Question it answers
Founder Handbook	Why is this product worth building, and for whom?
Knowledge	What have we learned or decided, and on what evidence?
Backlog	What bounded work might we do in a future release?
Workspace	What selected work is approved, active and ready to execute?
Product repositories	What code and tests implement the contract?
Release evidence	What was actually verified, against which source and artifact?

The important boundary is between possible work and authorized work.

A Knowledge decision can constrain implementation without authorizing a new release. A detailed Backlog proposal can be useful without being ready for implementation.

Backlog turns findings into achievable proposals

When I request proposal creation, an agent reads the relevant research, Founder direction, Runtime issues, previous release findings and existing candidates.

It checks for duplicates before creating another proposal.

Each release should stabilize one primary contract. Each candidate needs a bounded outcome, dependencies, explicit exclusions and acceptance evidence.

“Improve authentication” is too broad to execute reliably.

“Define source precedence, refuse ambiguous inputs, preserve identity across transports, and prove the behavior with these success and failure cases” gives an implementing agent something it can test.

Planning must also account for the work needed to qualify the release. A small code change with a large platform or credential matrix may still be an expensive release.

If the scope is too large, the agent can propose a split into additional releases. Each part must deliver a coherent outcome. Moving unfinished acceptance criteria elsewhere merely to declare success is not a valid split.

Our current roadmap reaches v0.20.0, but that is a planning horizon. Research and product evidence may justify more 0.x releases. v1.0 depends on an explicit readiness decision, not reaching a particular version number.

Parallel drafting is an explicit mode

Sequential release preparation remains the default.

When I explicitly ask for parallel proposal development, separate agents can refine different future releases in Backlog while the current release is being implemented.

They record their assigned proposals, inspected commits, predecessor dependencies and assumptions about unfinished code. Shared indexes and allocation files need coordinated editing.

Product reasoning may remain valid while code assumptions become stale. Before promotion, the agent refreshes those assumptions against the actual baseline and removes work that earlier releases already delivered.

This permits parallel preparation. It does not authorize parallel release implementation or a permanently running proposal factory.

Workspace promotion is a deliberate challenge

Backlog authoring and Workspace promotion are separate requests.

When I ask to promote the next planned release, the Workspace agent reconciles its proposals with current code, open issues, dogfooding findings and the release's primary contract.

The review must argue both sides:

• Why does this belong now?
• Why should it be deferred?
• What is already solved?
• Which dependency is still unsettled?
• Can a smaller change prove the same outcome?
• Is an acceptance criterion missing or impossible to verify?

The result is a proposed release scope for discussion.

Only the selected candidates enter Workspace. Later releases do not move automatically because their drafts look complete.

Approval accepts the contract. Activation authorizes implementation. Publication is another decision.

Human authority needs explicit boundaries

“Human in the loop” is not specific enough to tell an agent when it should stop.

Agent can prepare or perform within its assigned authority	Human decision retained
Research findings and proposal alternatives	Product direction and architectural changes
Recommended release membership and proposed splits	Acceptance of scope and allocation changes
Latest-code promotion challenge	Which candidates enter Workspace
Implementation plan and reviewable changes	Proposal approval and release activation
Test results and qualification report	Scope exceptions and publication authorization
Evidence-backed post-release issue reconciliation	Exceptions to the recorded closure requirements

Approval does not need to mean asking permission before every edit.

An agent should complete the work already authorized and present a concrete result. It should stop when a new decision changes the contract, crosses an authorization boundary or requires evidence it cannot obtain.

Written rules also need suitable repository permissions, review and operational discipline. A Markdown instruction by itself is not a technical security boundary.

A concrete lesson from the auth proposal

During v0.12.0 review, a first-run login question became visible: may an explicit login prompt when the execution surface is undeclared, observations are only local, and both input and output are terminals?

That choice affects usability and the no-prompt contract. It should not be silently decided by whichever coding agent reaches the condition first.

I approved the local first-run behavior, subject to the shared interaction gates. The proposal then recorded the choice consistently across the surface contract, context requirements and test expectations.

Further review identified missing undeclared-surface table cells and limits in enrolled configuration. Those became explicit rules and test requirements before implementation.

That is the value of proposal review: it turns an assumption into a decision an agent can implement and another reviewer can check.

It is still a design result. Passing implementation and qualification evidence must follow.

Let environments prove what they actually can

Cloud coding sessions are useful for bounded implementation, automated tests and reviewable PRs. I can initiate that work from my phone.

My Mac is useful for native interactive behavior and local credential flows. CI and the relevant live environments cover their own required platforms and provider paths.

A Linux fixture does not prove macOS credential-store isolation. A source build does not qualify a published archive. A successful local run does not establish that every CI or Kubernetes case passes.

The handoff should contain exact commits, commands, actual outcomes, untested cells and the next executable step.

This makes an environment change manageable without pretending that all environments are interchangeable.

Finish the loop after release

Issue triage should not end when implementation starts.

Our new release rule requires reconciliation of the considered issues after publication and required post-release verification, before the release is marked closed.

For a fully resolved issue, the coordinator links the fix, released version and relevant verification evidence, closes it, and confirms the resulting state.

A partially addressed issue stays open with its remaining work recorded. An issue that mentions a release is not necessarily fixed by that release.

Implementation PRs use non-closing references so a merge does not prematurely perform the post-release closure step.

Fresh-user testing adds another input: can someone using the released binary and public help complete realistic tasks without private source knowledge? Reproducible gaps feed issues and later planning.

The resulting evidence may change Knowledge, refine Backlog or challenge an earlier assumption. It should not disappear into the last agent's chat.

Context must survive a session ending

During this work, one coding session reached its usage limit. Another continued from repository state, review comments and the handoff.

The records were sufficient to verify merged work. They were not sufficient to infer an unstated next instruction, so that instruction had to be clarified.

That distinction matters. Durable context reduces reconstruction; it does not make missing decisions magically available.

The companion article GitHub as Agent Context describes why I keep decisions, proposals, PRs and evidence in versioned records.

A small starting point for another solo founder

You do not need to copy the whole repository layout.

Start with a decision log, an issue tracker, a Backlog folder and one release proposal.

For each release, write:

1. The user outcome and primary contract.
2. What is included and deliberately excluded.
3. The source baseline and dependencies.
4. The acceptance tests and required environments.
5. Who may approve, implement, merge and publish.
6. What evidence must remain, including issue disposition after release.

Add one research routine and one bounded review routine only if you have capacity to review their output.

The cost of this system is real: stale documents, duplicate proposals, excessive process and noisy findings can consume the time agents were supposed to save. Keep one canonical decision, update existing work, and add a rule when a concrete failure justifies it.

My next test is v0.12.0 itself: whether an agent can follow the proposal, whether another can verify it, and whether the released evidence justifies closing the original issues.

The useful outcome is a development process that preserves human judgment and leaves enough evidence for someone else to continue.