Earned Autonomy: Comparing My Agent Workflow with a Corporate Experiment

I came to Liberty roughly six months ago with a fairly strong opinion about what an AI coding agent should be doing.

Not autocomplete. Not a faster way to generate a function. Not a chat window that occasionally knows how to edit a file.

I had been building a working environment in which an agent could participate in most of the delivery lifecycle: understand a task, inspect the code, make a plan, change a small slice, run the right checks, prepare a pull request, and help work through what happened afterwards.

Now Liberty is starting to explore a more formal way of working with agents. The approach uses reusable agent skills and a more explicit, specification-driven sequence around planning, implementation, validation, and learning.

I find the comparison more useful than either approach in isolation. I already have a workflow that works for me. The company experiment gives me a chance to ask a harder question: which parts of that workflow are genuinely valuable, and which parts only feel valuable because I built them myself?

The interesting question is not whether an agent can act autonomously. It is whether its autonomy has been earned by context, rules, and evidence.

What I brought with me

My approach is based on earned autonomy.

That phrase matters. I don't mean giving an agent unlimited freedom and hoping that a capable model will make good decisions. I mean giving it room to move inside boundaries that are explicit enough to be checked.

In a typical task, the agent starts with a goal from a ticket or a conversation. It researches the relevant code and nearby context. It tries to find the code that actually controls the behavior instead of editing the first file that looks related. It identifies constraints, forms a local hypothesis about how the change should work, and chooses a cheap check that could prove the hypothesis wrong.

Then it changes a small slice and validates that change immediately. Broader checks come afterwards. When the work is ready, the agent can prepare a branch and a draft pull request, help investigate CI failures, and respond to review feedback.

The important part is not the length of that list. It is that the list describes a connected workflow rather than a collection of isolated prompts.

Context before cleverness

The workflow depends on several levels of context. There are personal rules about how I want an agent to work, shared engineering standards, and repository-specific instructions. More local and more current information should win over a general preference.

Memory helps the agent continue across sessions, but memory is not authority. The current code, tests, documentation, and actual tool output are more trustworthy than something saved from a previous conversation.

That distinction is easy to state and surprisingly important in practice. A remembered convention can be stale. A test failure in front of you cannot be argued away by a paragraph written last month.

Tools instead of context theatre

I also prefer integrations over manually copying the world into a prompt. When permitted, the agent can work with task systems, documentation, source code, tests, and pull requests through connected tools.

The benefit is not that the agent suddenly knows everything. It is that the relevant evidence can stay close to the task. Requirements, implementation, and validation do not have to be reconstructed from a chain of pasted fragments every time.

That still requires judgment. An integration can expose the wrong context just as efficiently as the right one. Tools expand an agent's reach; they don't decide what deserves attention.

The human is still the owner

An agent can research, edit, test, and prepare changes. It does not own the requirements, the architecture decision, the approval, or the final review.

That is not a ceremonial disclaimer. It is part of the design. Autonomy is useful when it removes mechanical coordination and preserves human attention for decisions that carry real risk. If a workflow asks a person to approve every harmless step, it has not created autonomy. It has created a queue of tiny approvals.

What Liberty is exploring

The approach Liberty is beginning to investigate puts more structure around the work. It uses reusable agent skills: packages of instructions and working patterns that help an agent perform a particular kind of engineering task more consistently.

A skill might support context discovery, planning, implementation, debugging, or review. It is not another intelligent employee. It is a reusable description of how to approach a task, with the aim of making useful practices easier to repeat across engineers and repositories.

The broader lifecycle is more explicit than the one I normally follow informally:

Prepare the relevant instructions and context.
Clarify or create a specification.
Produce a plan.
Review the plan.
Implement the change.
Validate the result.
Record observations about quality and usability.

There is a lot to like here. A team cannot rely on one engineer having spent months tuning a personal workflow. Reusable skills offer a possible common language. They might help engineers with different levels of experience start from a better baseline, and they create a clearer shape for comparing what happened across tasks.

The experiment is still early. Liberty is exploring and piloting this kind of systematic approach; it has not produced a final company-wide process or a conclusion about fully autonomous software development. That distinction matters because the value of the experiment is precisely that the result is not known yet.

Where the approaches meet

The overlap is larger than the difference.

Both approaches assume that an agent needs good context before it needs more freedom. Both treat clear requirements, planning, small changes, tests, and human review as controls rather than optional polish. Both value reusable knowledge, because repeating the same explanation in every session is a poor use of anyone's time.

Both also suggest that speed of generation is an incomplete measure. A change that appears quickly but needs extensive correction is not necessarily faster. The useful question includes quality, traceability, review effort, and what happens when the next engineer has to understand the result.

That is why I don't see reusable skills as the opposite of my workflow. They may be a way to package some of its useful habits so that they are less dependent on personal configuration. They may also expose parts of my process that are too implicit to teach to anyone else.

Where I am cautious

The concerns I have are hypotheses, not verdicts. The experiment needs to test them.

The first is process proportionality. A full specification, plan, review, implementation, and reporting sequence makes sense for risky or complex work. For a tiny, obvious change, it may create more text and more transitions than value. A good engineering process should scale with the risk of the task, not apply the same ceremony to everything.

The second is that artifacts can become the goal. A detailed specification can still describe a wrong assumption. An agent can produce a polished plan for a problem nobody actually has. Evidence and useful questions matter more than document length.

The third is the cost of formal stopping points. If a person must confirm every safe step, the workflow can become a stream of interruptions. My current model delegates many low-risk decisions through standing rules and brings a human in where the risk changes. I want to know whether a more formal process can preserve that shape.

There is also a locality problem. A reusable skill can explain how to plan or validate in general, but it cannot automatically know a repository's architecture, conventions, environmental limits, or history of decisions. Without that local layer, a skill can produce work that sounds reasonable and still does not belong in the system.

Finally, attribution will be difficult. If a task goes well, the cause might be the skill, the repository instructions, the connected tools, the tests, the quality of the original request, or the engineer's own experience. A fair experiment has to separate those effects as much as it reasonably can.

Reporting has a cost too. Tracking corrections, defects, rework, and subjective experience is necessary for an honest comparison. But if reporting takes a meaningful amount of engineering time, that time is part of the result, not an inconvenient detail to hide.

What I want to learn

I am not joining this experiment to prove that my existing approach is already the answer. That would make the comparison pointless.

I want to find out which skills prevent mistakes that would otherwise reach review. Where does an explicit specification improve the result, and where does it add ceremony? Does the process help an agent recover context in a new session? How much human correction is actually required? What happens to review quality and cost?

The useful comparison will come from real tasks, not from a polished demonstration. For each task, I would want to understand whether the acceptance criteria were met, how much correction and rework appeared, which defects were found by the agent, CI, or a person, and which parts of the framework produced observable value.

I would also separate ordinary engineering effort from framework overhead and reporting time. Those are different costs. Combining them into one number would make the result look cleaner while making it less informative.

The data will need to be aggregated and anonymized. The goal is to learn about the workflow, not to publish internal details or turn a small experiment into a claim about the whole company.

This is the beginning, not the conclusion

There is a temptation to choose a winner early. Personal workflows feel concrete because you can see their history. Formal frameworks feel credible because they have names, stages, and reusable artifacts. Neither feeling is evidence.

My current expectation is that the useful outcome will be a combination. Some skills may capture practices worth making more consistent. Some formal stages may be valuable only for certain classes of work. Some of my existing rules may turn out to be personal preferences rather than durable engineering principles.

That is a good result. The point is not to protect a workflow because I built it, or to accept a framework because it arrived with a process diagram. The point is to discover which controls help an agent do better work while leaving people responsible for the decisions that matter.

I am at the beginning of that comparison now. Later, once there is enough evidence and the results have been checked for accuracy and confidentiality, I'll come back with what actually happened: where reusable skills helped, where they added friction, and what I changed in my own way of working.

Until then, I am keeping the conclusion deliberately open. An agent does not become trustworthy because it has more freedom, more documents, or more steps. It becomes more trustworthy when the system around it makes good decisions easier to verify.

If you've been comparing a personal agent workflow with a more formal team process, I'd be interested in what you measured. The difference between a convincing demo and a useful engineering system usually appears only after the first few ordinary tasks.