Clip / AI Agents

Actuator: an agent plus a skill seeded with hand-written golden patterns

From Loop Engineering from First Principles — Kyle Mistele, HumanLayer · ≈12:34

“Our actuator is just an agent plus a skill. Um bring your CLI coding agent of choice. You should spend a lot of time on the skill. Not all of that should be up front. You'll want to iterate on it over time based on what works.”
AI Engineer

“At Human Layer, we like to build out what we call golden patterns by hand before setting the agent loose. These are just like idiomatic handwritten examples for the agent to follow because they're just pattern replicators and otherwise you're getting what's in the docs or what the agent knows from the internet.”
AI Engineer

“my recommendation is to use GitHub actions or your GitLab or your CircleCI or whatever else you're using because it has access to your code, it has access to your secrets, and it has great dispatch and scheduling primitives, right? We don't need a new cluster for this.”
AI Engineer

“And when we first did this it was actually really frustrating and we turned loop off and it cuz we had to constantly update the skill, we had to constantly check out the branch, change the skill, change the code, commit and push, and our loop was actually really high friction, right?”
AI Engineer

“And the benefit of doing this way is that now that feedback file with instructions is tracked in your version control, you can see how you've changed it over time, you can revert it if you need to.”
AI Engineer

What’s in it

Without hand-authored exemplars the agent reproduces whatever it learned from the internet; pairing the skill with a scheduled CI workflow (existing secrets, dispatch and scheduling — no new cluster) yields one small low-risk PR per morning.

Watch this moment

Clip transcript

Oh, man. There we go. So next is building our actuator. Our actuator is just an agent plus a skill. Um bring your CLI coding agent of choice. You should spend a lot of time on the skill. Not all of that should be up front. You'll want to iterate on it over time based on what works. At Human Layer, we like to build out what we call golden patterns by hand before setting the agent loose. These are just like idiomatic handwritten examples for the agent to follow because they're just pattern replicators and otherwise you're getting what's in the docs or what the agent knows from the internet. And so we pipe the skill plus our control signal into our actuator agent. And if the skill of course should include a response template, and the agent's going to work and work and work, and it'll produce a final response, and then we're going to deterministically commit and push and create a PR using the final message as our PR description. Now all we have to do is actually run the loop, right? Uh my recommendation is to use GitHub actions or your GitLab or your CircleCI or whatever else you're using because it has access to your code, it has access to your secrets, and it has great dispatch and scheduling primitives, right? We don't need a new cluster for this. So, we can write a workflow that runs a single iteration of the loop, sense, control, actuate, and creates a PR. And then we can schedule this to run once a day. And every morning we walk into the office to a small incremental PR that's low risk. And when we first did this it was actually really frustrating and we turned loop off and it cuz we had to constantly update the skill, we had to constantly check out the branch, change the skill, change the code, commit and push, and our loop was actually really high friction, right? But there's a better way to do this uh where we can put a human on the loop in a really low friction way to re-steer it when it goes wrong. And the way to do this is to just create a feedback file that's tracked in version control just as a markdown file, right? We can deterministically load it into our actuator agent's context every time that it runs after we run the controller. Then we can add a label to the PR, right? Each workflow needs to be able to identify PRs that it created since there might be a bunch of different loops running and we only want workflows to respond to feedback from uh comments on their PRs. And we're going to add a comment trigger to each loop workflow. So, the when a user leaves a {slash} iterate comment on the PR uh the loop workflow is going to pick that up, it's going to deterministically load all of the PR context, the diff, the comments, the review comments, the description into the agent's context along with the skill, and it's going to instruct the agent to fix the code, but also to update that feedback file, right? It looks kind of like this. And the benefit of doing this way is that now that feedback file with instructions is tracked in your version control, you can see how you've changed it over time, you can revert it if you need to.