One of my least favorite instructions to give an agent is: we already solved this in another repository. Go find those files and do something like that here.
The capability exists. But it lives inside another script, with another set of assumptions. I still have to find it, choose which files to share, and help the agent reconstruct something we already built.
AI makes that reconstruction much easier. I would rather not need it.
That is still my favorite use of Swamp: reusable operations I can compose into new solutions, not just code an agent can copy.
What behavior-centric design changes
I am grateful to be building during this wave of AI progress. I expect AI to become a bigger part of my work, not a smaller one. But I want to start with the behavior I need, rather than assume an agent should run the whole process.
In an agent-centric flow, the model receives a goal, chooses a tool, reads the result, and decides what to do next. That flexibility is useful when exploring an unfamiliar problem. For a settled procedure, it means repeatedly asking a model to make decisions we could already have encoded.
Behavior-centric design makes the operation the reusable unit. Define what it accepts, what it does, and what result it produces. Compose those operations into a workflow that owns the sequence, conditions, and failure handling. A model can interpret a request or assess a review comment within that workflow without having to orchestrate everything around it.
In Swamp, those operations are methods on typed models, with validated inputs and outputs, versioned data, and credentials referenced through vaults. Workflows connect the methods and pass their results onward. That shared structure is what my scattered scripts were missing.
AI has two useful roles here: helping me build and maintain the behaviors, and doing specific reasoning jobs when they run. This is not just a script wrapped around an open-ended agent. The workflow controls when intelligence is called and what can happen with its answer.
One set of capabilities, several uses
In Wrangling Agents With Repeatable Tools, I described a recurring job: help me manage a stack of PRs. Find failing CI, assess review comments against the code, and prepare fixes or replies.
Scheduled methods now refresh recorded PR, CI, and ticket state. Code selects feedback that needs attention. Scoped agents assess comments against the source and prepare suggestions. Posting a reply or applying a change is a separate action.
One comment exposed a mismatch: a project's image count included collaborator photos, but its photo-selection logic allowed only the company's own photos. The suggested fix checked the eligible count before choosing a project. Understanding that mismatch is a useful model job. Deciding whether it is time to poll GitHub is not.
My software factory makes that distinction concrete. Agents help plan, implement, and review changes. Runtime methods execute declared checks and record whether the evidence passed, failed, or is missing. An agent can diagnose a failed test; it does not need to rediscover how to run the suite, and its confidence is not the test result.
Those behaviors are useful outside the factory, too. My cli-agent extension serves PR-comment triage and CI repair as well as the factory. The factory's worktree operations also support the PR dashboard's fix path. I am not just reusing code. I am reusing operations with defined inputs, results, and execution boundaries.
Community extensions extend that beyond my own work. Someone else may already have built the integration I need.
Judgment still belongs in the process
Planning remains heavily paired work between me and an agent. We explore alternatives and challenge assumptions, but I make the final decisions. For the mechanics, I want code: linting, running tests, setting up environments, and tearing them down.
That is the division I described in Amp Is the Harness, Swamp Is the Runtime. It is not a reason to encode every decision as a rigid rule.
My factory accumulated enough checks and handoffs that I had to scale it back. One check rejected a planner's trailing punctuation when it was supposed to verify intent. Required fields are something code can check. Whether a plan makes sense is a different question.
Deterministic does not mean infallible. APIs fail, assumptions go stale, and bounded model calls can still be wrong. An explicit procedure makes the work easier to inspect and repair; it does not remove my responsibility to decide whether that procedure serves the goal.
Beyond software delivery
The same approach shows up in other things I have built:
- An offline meeting transcriber, composing local transcription, speaker identification, and summarization.
- A road-trip watcher that became a home alert system, adapting the capability after the trip ended.
- Homelab storage alerts, reusing an existing notification model.
- A packing-list model, separating a repeatable preview from a confirmed action that creates real tasks.
Why I am glad this team is building it
In Discord and on the podcast, I have appreciated the team's balance: enthusiasm for what AI can do without treating engineering experience as obsolete, or dismissing the tools because they have limitations. That experience comes through in how they discuss current AI news. It is a perspective I value while building with these tools myself.
Swamp is announcing its launch and a $7 million seed round led by Amplify Partners today. Congratulations to the team.
If you are asking agents to recreate the same integration or execution procedure across projects, take a look at Swamp. Start with one repeated job, define its behavior, and give the next workflow something it can use.
I want AI to help me solve more problems. I do not want to keep solving the same ones.
Disclosure: I am an independent Swamp user. This post is not sponsored.