From AI-assisted work to a governed execution model

AI changed both how I organized work and how many different ideas I could take into practice.

At first I controlled every AI step. As the projects progressed, control shifted toward the desired outcome, context, work decomposition, boundaries, verification and the final result. At the same time, I was able to test several very different projects within one summer. That is a qualitative observation of increased execution capacity, not a measured productivity claim.

7 different casessoftware development, 3D, a service, deterministic checking, decision analysis, context engineering and MCP

One agent → subagentsdecomposing work into planner, implementer and reviewer roles

Prompt → working systemcontext, tool use, execution loop, guardrails and review

Speed → evidencemore execution capacity does not remove the need to verify the outcome

Leadership lens: the outcome of the experiments is not another AI tool, but a governed execution model for designing work around AI.

As autonomy increases, leadership shifts toward outcomes, context, decision rights, evidence, guardrails, verification and human gates. The model structures execution; in enterprise use it still depends on the organization’s wider governance and decision structures.

Enterprise boundary: in production, this execution model would sit inside existing organizational controls for data protection, information security, regulatory obligations, vendor risk and decision rights rather than replace them.

Learning journey

This is not a maturity model or a score. It is a chronological description of how my way of working changed across the projects.

StartPrompt & response

Individual requests.

Next phaseAI pair worker

One step and approval at a time.

Repo workAgent for an end-to-end task

Multi-file changes, tests and diff.

Bounded autonomyWorkflow + guardrails

Goal, boundaries, context and human gate.

LaterSubagent orchestration

Decomposing the task across different agent roles.

Projects as learning environments

The number of projects is not a success metric in itself. The value was being able to take seven different ideas to a practical level and test the same principles against very different problems.

Rovo / Project SourcesTest:persistent context, decision log, evidence/status rules.Lesson:The context layer is the agent’s working memory and governance, not merely a document repository.

PDF CheckerTest:External veraPDF engine, Docker runtime and JSON reporting.Lesson:The agent has to understand not only source code, but also runtime, external dependencies and what can be verified deterministically in the outcome.

AjokeliTest:APIs, data processing, map visualization and user interface.Lesson:A conventional data/web application was a useful baseline for how an agent handles ordinary full-stack work end to end.

SatsiTest:Cloudflare D1, database schema, auth, domain modelling and the data structure required by a barcode reader.Lesson:An agent can also take an application with a persistent data layer end to end when the schema and acceptance criteria are explicit.

GhostlightTest:Three separate development rounds: V1 what AI can produce, V2 deeper planning and V3 a deliberate attempt to exceed the previous level.Lesson:Technical verification is not enough; planning, iteration and visual/UX review form a separate quality layer.

Blender + MCPTest:Taking MCP and harness skills further by connecting the agent to an external 3D tool.Lesson:Tool use increases capability, but permission, data, context and trust boundaries become part of implementation design at the same time.

Capital investment decision analysisTest:RFP, financing analysis, calculator and decision material.Lesson:Facts, calculation and interpretation must be separated. Agentic ways of working also apply to knowledge work.

Throughput lesson:AI enabled several different projects to move from idea to working artifact within one summer. This is a qualitative observation of increased leverage, but it is not a measured productivity metric.

LeverageMore execution capacity is a hypothesis of value, not a business case without a baseline.

ManagementWith AI, leaders increasingly manage the objective, context, boundaries and control points.

SelectionAgentic work fits best where tasks are bounded, verifiable and reversible.

ScaleOrganization-wide adoption should follow measured pilots, not precede them.

Visual evidence

Images do not replace technical evaluation, but they make it immediately visible that the cases were different from each other and progressed to working artifacts.

PDF Accessibility CheckerveraPDF engine, Docker runtime and a deterministically reportable result from a machine-readable rule set. Automated checking covers only part of PDF/UA requirements.pdf.watisdis.com

SatsiFull-stack + Cloudflare D1 + schema/domain modelling.satsi.watisdis.com

AjokeliAPI data → processing → map visualization → UI.ajokeli.watisdis.com

GitHub repositories for Ghostlight, Satsi, Ajokeli and PDF Accessibility Checker

GitHub / repo-aware developmentProjects under version control; repository, branch, diff and tests formed a controlled working environment for agentic development.

Ghostlight · V33D/visual result from the third development round.ghostlight.watisdis.com

Blender project showing a rig, 3D character and script in the same workspace

Blender + MCPTool use and the harness as the research subject: the agent connected to an external 3D application.

Workflow evolution: from advisory AI to a tool-enabled agent

The clearest practical change was not the model name, but what the agent could do in its environment. In the first projects, many configuration steps were manual; later, repo and tool integrations, and MCP in separate cases, became part of the same execution loop.

1 · ManualAI advises

Code and solutions were produced with AI assistance, but I configured GitHub, domains, subdomains and Cloudflare myself.

2 · Repo-awareGitHub becomes part of the workflow

Repository, branch, files, tests and diff review brought changes into a controlled and reversible working environment.

3 · Tool-enabledTool access + MCP

GitHub and Cloudflare access came through native integrations, CLI/API tools or add-ons. I used MCP separately, for example to connect Blender as an agent tool.

4 · Harness-drivenOne governed loop

Research → change → test → version control → configure/deploy → verify, with a human gate at critical points.

What I would do differently now:I would bring GitHub and Cloudflare tool access in earlier. Experiencing the manual and integrated approaches sequentially made the difference concrete, however: an agent becomes more valuable when it can act within bounded permissions in the real environment instead of only giving instructions.

AjokeliAPI + data + visualization + UIBaseline for more conventional full-stack/data work.

Satsi+ D1 + schema + domain modellingPersistent data and modelling increased complexity.

PDF Checker+ external engine + Docker/runtimeThe agent had to account for the runtime environment and deterministic verification as well.

Ghostlight V1→V3+ deliberate iteration + visual reviewThe focus shifted from “does it work?” to “how much can the workflow improve quality?”

Blender + MCP+ external tool useMCP and the harness themselves became research subjects.

Rovo / Project Sources+ persistent context + evidence governanceEventually the focus also shifted toward what the agent knows and what it is allowed to trust.

One important failure: a good structure does not rescue bad evidence

Rovo / Project Sources

In one work phase, a claim based on a design document ended up with an overly strong “confirmed” status. The problem was not language-model fluency but the evidence hierarchy: a design document described the intended solution, not verified production behavior.

What changed because of this

The strength of a claim must not exceed the strength of its source. Design, implementation, test result and production observation need to be separated. This led to tighter evidence/status rules and reinforced the view that the agent’s context layer needs an explicit reliability model.

Key lesson:an agent can be internally fully logical and still reach the wrong confidence level if source authority or the status model is wrong.

From one agent to an agent team

Subagents entered the workflow only in the later projects. Their value was not “more AI”, but dividing work into purposeful roles.

Planner / researcher

Research before implementation

Explores alternatives, dependencies and risks before implementation. Reduces premature lock-in to the first solution.

Implementer

Bounded implementation responsibility

Receives a clear task, required context and acceptance criteria. The focus stays on implementation.

Reviewer / verifier

Independent review

Assesses the diff, tests and requirement coverage separately from the implementer. In practice, a separate AI-assisted review pass.

When it helps

When the work can genuinely be decomposed

Parallel, independent research or implementation tasks
Different roles: research, implementation, testing, review
A need to limit the context load of one agent
A need for an independent second assessment

When it does not help

Orchestration itself has a cost

A small or linear task
A lot of shared changing state and synchronization
Handoffs lose more context than they add value
Roles or responsibilities are unclear

What does reliable agentic work actually require?

This is a practical checklist, not a formal maturity model. Model intelligence is only one part of the whole.

Context

What the agent knows

Current state, backlog, decisions, evidence, vocabulary, repository and task boundaries. Outdated or wrong context quickly scales into wrong execution.

Harness / execution environment

How the agent operates

The execution environment and tool loop around the agent: how context is supplied, tools are called, feedback is handled, state is maintained and execution continues.

Verification & control

How we know the result is acceptable

Tests, diff, visual review, evidence hierarchy, bounded permissions and human gates according to risk.

Context and control layers in practice Not everything should be pushed into one prompt. Changing project state, reusable working instructions, action boundaries and evidence reliability are different concerns.

Project context

What is known about this project now

Current state, backlog, decisions, changelog, open items and domain-specific information.

Reusable instructions / skills

How a certain kind of work is done

Recurring planning, implementation, review and verification practices kept separate from changing project state.

Guardrails

What the agent is allowed to do

Scope, permissions, acceptance criteria, human-gate points and things that must not be changed.

Evidence

Which claims can be trusted

Source authority, status and confidence. A claim must not be stronger than its source.

Practical implementation:in my projects, persistent context meant structures such as project state, backlog, changelog and decisions. The point was not the file names, but that the agent did not have to infer from scratch in every session where the project stood and how work should be done.

Heuristic whole:model + context + execution harness + tools + guardrails + verification. A weak layer in any one of these can quickly show up in the outcome.

Autonomy: two different questions

Verifiability and reversibilitydetermine how much of a task can be delegated.Riskdetermines how high the control threshold needs to be.

Easy to verify / reverse

Hard to verify / reverse

Low risk

High autonomy can be possible

For example, bounded research or a code change where tests and rollback are clear.

Bounded autonomy

The agent can prepare the result, but a human checks it before proceeding.

High risk

Autonomy + strong human gate

Automation can do a lot, but the decision or publication gate remains with a human.

Strong human control

AI can support analysis but should not make the final decision or irreversible action.

Failure modes I learned to take seriously

Problems in agentic work are not limited to hallucinations. When an agent gets tools and a longer execution chain, the surface area for errors also grows.

Outdated / wrong context

A correctly executed task can still be based on the wrong current state.

Confident wrong result

A fluent explanation is not evidence.

Silent regression

One target is achieved while something else breaks.

Test gaming

The agent may change the test to match the implementation instead of changing the implementation to match the requirement.

Spec drift

A long execution can drift away from the original goal.

Shared state / handoff

Parallel agents can end up with conflicting information or changes.

Prompt injection

External web, document or tool content can attempt to steer the agent away from the original task.

Permissions that are too broad

Tool use increases both capability and the potential impact of mistakes.

Runaway cost / loops

More agents or a long retry chain do not automatically improve quality.

The workflow the work converged on

Define the user outcome

What does the user or business need to achieve?

Provide the right context and evidence

Repository, current state, backlog, decisions, data, vocabulary and source authority.

Define guardrails

Scope, permissions, acceptance criteria and what must not be changed.

Decompose the work and choose agent roles

One agent, parallel subagents or planner → implementer → reviewer.

Isolate the change

Branch / workspace so reversibility is preserved.

Delegate execution

The agent or agents research, implement, test and iterate within bounded responsibility.

Verify independently

Build, lint, tests, UX/use case, evidence or a separate reviewer.

Human gate according to risk

Critical decision, merge or production action remains with a human.

Update project memory

Return decisions, status, changelog and open items to persistent context.

What next: from leverage to bounded end-to-end delivery

The next step would be to test the model in a real work environment using one small, recurring and reversible change type. The goal would not be to automate the entire delivery process at once, but to determine progressively how much of it AI can execute safely and measurably while humans retain decision accountability.

Pilot design

A bounded end-to-end agentic delivery pilot

The pilot case would be selected for measurable verification and repeated often enough to create a real comparison — not a one-off demonstration.

Selection criterionRecurringSufficient comparable cases to establish a baseline

Selection criterionReversibleBounded blast radius and recoverable actions

Selection criterionVerifiableOutcome testable through rules, tests or metrics — not judgement alone

Bounded delivery pathAI executes inside defined scope; humans retain decision accountability

Needoutcome

Impactaffected scopeHuman gate · impact approval

DesignsolutionHuman gate · solution / architecture

Buildexecution

Testevidence

Reviewed candidaterelease remains human-ownedHuman gate · release decision

Bounded execution: AI would operate only within a predefined task scope, tools, data and permissions, with defined verification, escalation and traceability requirements.

Enterprise data boundary: internal data would additionally require bounded identities and permissions, secrets management, an audit trail, clear data boundaries, and compatible contractual, processing and retention terms.

Evidence boundary: In these experiments, I was both the delegator and the verifier. A bounded enterprise pilot would need to test whether human gates remain effective under distributed accountability, review capacity and delivery pressure.

01BaselineMeasure enough comparable cases: cycle time, production vs verification effort, quality, rework and cost per change.

02Bounded workflowDefine context, evidence, permitted tools, prohibited actions, verification, gates and traceability.

03CompareUse the same core measures, then add missed impacts, later defects, control effectiveness, escalations, human intervention and reviewer confidence.

04DecideProgress only where the evidence supports it. Otherwise change the operating model or stop.

Two separate decisions, in sequenceMore scope does not automatically mean more autonomy.

Decision AExpand scopeExtend the workflow across more of the delivery chain while keeping human gates intact.

→

Decision BIncrease autonomyOnly where verification and controls have already demonstrated sufficient reliability.

Leadership takeaway: the goal is not maximum autonomy, but the highest level of autonomy in enterprise delivery that is safe, verifiable and demonstrably valuable. Autonomy is not the starting assumption; it is earned through evidence. If the evidence does not support progression, change the operating model or stop.