In many AI projects, the most common type of “technical debt” is as follows:
It started as a prompt,
Later, a few more lines of rules were added,
and then stuffed in tool calls, conditional branching, exception handling,
In the end, it became a “super prompt” that no one dared to change.
wshobson/agents This project focuses on the problem itself:
How should we “engineer” AI when it is no longer just chatting but engaging in real tasks.
1. What is the core goal of this project?
Summary in one sentence:
Defining, organizing, and combining AI Agents in software engineering rather than heaping prompts.
It doesn’t try:
- Deliver an AI product out of the box
- Show how strong a model is
Instead, it solves a more underlying problem:
How the Agent should be “written into code”, not “written as text”.
2. Why are prompts not enough in engineering?
In the prototype stage, prompts work well;
But at the engineering stage, it has several fatal problems:
1️ Not maintainable
- The more rules, the longer the prompt
- Changing one place is likely to affect the overall behavior
- There is no clear “boundary of responsibility”
2️ It cannot be used again
- A Prompt is bound to a task
- It is difficult to extract “analysis ability” and “verification ability” to reuse them separately
3️ Collaborative is not possible
- All tasks are given to the same model
- Reasoning, execution, and verification are mixed
agents The position of this project is clear:
These are not model problems, but structural problems.
3. What does Agent mean in this project?
wshobson/agents In the design of :
Agent ≠ a prompt
Agent = Role + Responsibility + Behavior Constraints
An agent typically has:
- Clear role positioning (only do one type of thing)
- Stable input/output expectations
- Fixed ways of working, not “just play”
This is very similar to the concept in the backend:
| Back-end system | AI system |
|---|---|
| Service | Agent |
| Controller Responsibilities | Agent role |
| API input and output | Agent I/O |
| Call chain | Agent Pipeline |
4. Multi-agent, not “universal AI”
One of the most important engineering ideas for this project was:
Don’t try to do everything with one agent.
Instead, it is divided into multiple agents with a single responsibility, such as:
- Analysis Agent: Only responsible for understanding problems and disassembling tasks
- Execution Agent: Responsible for specific builds or operations
- Validation Agent: It is only responsible for checking, correcting errors, and constraining output
Engineering-wise, this brings several clear benefits:
More stable
The scope of each agent’s behavior is controllable.
Easier to debug
You can clearly know:
Which step went wrong, not “the model is not in good shape today”.
Easier to scale
When new requirements are added, they are often the following:
- Add an Agent
- or replace an agent
Instead of rewriting the entire prompt.
5. This is not a demo, but a “structural demonstration”
wshobson/agents The code itself is not complicated,
But its value lies not in the “implementation skills”, but in the choice of structure:
- Agents are first-class citizens
- The collaborative relationship is explicit
- Behaviors can be combined
This makes it more like:
Minimum Viable Architecture for an Agent System
Instead of teaching toy examples.
6. Evaluation from the perspective of engineering
From an engineering perspective, my judgment is:
This is a project that is “not complicated in code, but very well oriented”.
It doesn’t solve all the problems, but at least clarifies one thing:
When AI enters engineering, it must be designed like software modules, not built on inspiration.
If Prompt is the “scripting era”,
This agent structure is clearly moving towards the “system era”.
Epilogue
wshobson/agents It doesn’t directly improve your model capabilities.
But it will greatly increase the ceiling of how much you can build AI systems.
For those who really want to use AI as an engineering component,
This kind of project is worth studying repeatedly.
Github：https://github.com/wshobson/agents
Tubing: