What if AI agents could both create new automations and directly reuse existing ones?
This idea builds on my earlier post about turning solved edge cases into reusable automation.
The first idea focused mainly on how an AI system could solve a new operational problem, verify the solution, and turn that solution into a reusable automation.
But there is another important part:
What should happen the next time the same task appears?
Today, many agent architectures work roughly like this:
flowchart TD
A[User request] --> B[Agent]
B --> C[LLM reasoning]
C --> D[Generate commands or scripts]
D --> E[Agent executes them]
E --> F[Return result]
This works, but it means the system may repeatedly reason about and reconstruct operations that have already been solved before.
For many infrastructure tasks, that should not be necessary.
If a task has already been solved, tested, approved, and stored as automation, the LLM should be able to trigger that automation directly.
For example:
User:
“Restart the payments deployment in production.”
flowchart TD
A["User: Restart the payments deployment in production"] --> B["LLM identifies the operation: k8s.rollout.restart"]
B --> C[Automation Registry]
C --> D[Policy + parameter validation]
D --> E[Verified automation executes]
E --> F[Result + evidence returned]
The LLM does not need credentials.
It does not need the Kubernetes token, Azure secret, AWS key, SSH password, or Vault secret.
Those remain inside the local or cloud execution environment.
The LLM only needs to describe what should happen.
For example:
{
"automation": "k8s.rollout.restart",
"environment": "production",
"namespace": "payments",
"deployment": "payments-api"
}
The execution system already knows:
-
where the automation runs
-
which identity it uses
-
which permissions are required
-
where credentials are stored
-
which safety checks must pass
-
how success is verified
-
how rollback works
-
what evidence should be recorded
This gives the system two different paths.
- Known operation
If a verified automation already exists:
flowchart TD
A[Intent] --> B[Automation Registry]
B --> C[Policy / Validation]
C --> D[Verified Automation]
D --> E[Executor]
E --> F[Infrastructure]
F --> G[Verification / Evidence]
Very little reasoning is required.
- Unknown problem
If no suitable automation exists:
flowchart TD
A[Problem] --> B[AI Investigation]
B --> C[Find Solution]
C --> D[Test]
D --> E[Verify]
E --> F[Create Automation]
F --> G[Approval / Policy]
G --> H[Automation Registry]
The important part is what happens afterward.
The next time that same problem appears, it is no longer an unknown problem.
It becomes a known operation.
So the complete lifecycle becomes:
flowchart LR
A[Discover] --> B[Solve]
B --> C[Verify]
C --> D[Automate]
D --> E[Register]
E --> F[Invoke]
F --> G[Observe]
G --> H[Improve]
Over time, the system builds a growing library of verified capabilities.
Examples for infrastructure could include:
vm.create
vm.resize
vm.restart
k8s.deploy
k8s.rollback
k8s.scale
k8s.rollout.restart
terraform.plan
terraform.deploy
dns.record.create
certificate.rotate
backup.restore
The LLM becomes the decision layer.
The automation system becomes the execution layer.
The Vault or identity system handles credentials.
The policy layer controls what is allowed.
And the automation registry becomes the operational memory of the system.
The interesting consequence is that the system should require less repeated inference over time.
New problems still require reasoning.
Known problems increasingly become deterministic execution.
So instead of asking an AI agent to repeatedly generate shell commands for operations it already understands, we could move toward a model where:
AI reasons when necessary, but automation executes whenever possible.
Or even more simply:
Solve once. Verify once. Automate it. Reuse it. Reason again only when reality changes.