Growing Wild: How I Rebuilt My Agent Architecture Through Vibe Coding
Translated from the original Chinese article.
The beginning: a Vibe Coding experiment
A few days ago I used Vibe Coding and the Feishu Task MCP in my IDE to develop a small scheduling project. My main need was to manage my daily schedule, meetings and work tasks by talking to AI, then synchronize them with Feishu.
To make the experience smoother and use fewer tokens, I created an Agent and several Skills specifically to pass information efficiently through the process. I found myself acting as an “architect,” repeatedly refactoring the Agent and Skills so the whole experience would flow. I did not consult official definitions or documentation during the process; I kept asking myself: what would feel best to use—what is the vibe?
My answer came down to two things: fewer tokens and higher efficiency.
My architecture philosophy: three practical principles
To make the system as efficient as possible, I experimented with design principles for three core concepts. I wanted to state a need, have the right Agent called quickly and have it execute efficiently, with low overall resource use. Here are my principles so far.
Prefer Skills, and make their actions atomic, independently usable and comprehensive in scope
- A design I avoid: writing a
manage_feishu.pythat reads, writes and cleans data all in one place. - My design: write a dedicated Feishu reading Skill, aiming for atomic actions, independent use and complete coverage.
- Atomic actions: the Skill handles reading from Feishu, not analysis or writing.
- Independent use: it is not tied to any Agent, although examples of typical call scenarios appear in SOPs. Like a hammer, anyone can pick it up and use it.
- Comprehensive scope: Feishu MCP reading capabilities—such as reading documents, schedules and calendars—are packaged together in this Skill.
When Skills are frequently chained, package them in a minimal Agent instruction
As the number of Skills grows, some tasks require several to be orchestrated. Only after a chain appears repeatedly, two or three times, do I introduce a workflow. My principle is to bundle Skills frequently combined in a particular situation into a representative SOP, expressed as concisely as possible in the Agent's prompt.
- Scenario: I made a scheduling Agent to manage my schedule. Sometimes, when I don't know what to work on, I ask it to suggest tasks based on my current and past schedule and my file structure. When I choose a suggestion, it writes that task into Feishu.
- Workflow injection: I package this frequent scenario as a concise prompt in the definition of
content-executor-agent. It has three parts: trigger, process and outcome. The trigger describes the scenario in one sentence; the process defines Skill 1 → Skill 2 → Skill 3; the outcome describes the intended final result. - Key principle: package frequent needs through minimal Skill orchestration. I formalize an action as a workflow only after it has recurred at least three times.
An Agent acts as the person responsible for a business area: it thinks, decides and calls Workflows and Skills
- An Agent is the person chiefly responsible for getting a category of work done. I have a dedicated content Agent and a code Agent for their respective areas. An Agent that manages Agents—HR—handles role definitions, organizational context, and the allocation of Skills and tools.
- Key principle: Agent = a person responsible for executing a category of business + memory of organization and execution rules + representative execution SOPs + Skills/MCP.
The efficiency idea: telegram style and mathematical language
To make the system run faster, I even established a base-language rule: relevant documentation should primarily combine mathematical or code-like language with English, while Chinese handles core explanations and annotations. I plan to explain why I think this way in a separate piece; follow along if interested.
This “High Conversion, Low Entropy” way of communicating showed me a possible path to an efficient system.
Reality check: my approach versus the official definitions
Only after doing all this did I read the official OpenAI and Anthropic documentation. Interestingly, I found some convergence as well as substantial differences:
| Dimension | 🏛️ Official definition (the textbook) | 🛠️ My organic approach (the vibe) |
|---|---|---|
| Agent | An autonomous loop, emphasizing its own thinking, planning and reflection. | An SOP executor. I need it to execute my workflow reliably, not to have too many ideas of its own. |
| Skill | Function calling, an accessory bound to an Agent. | Shared infrastructure: an atomic system capability completely independent of Agents. |
| Workflow | A DAG, with complex code orchestration. | A prompt chain: a few lines of instructions injected into an Agent. |
My advantages:
- Fast: developing a new Agent requires only a Markdown file.
- Reliable: atomic Skills rarely go wrong and can be used by anyone.
- Satisfying: it is intuitive and simple, like building with blocks.
My disadvantage:
- Less intelligent: the Agent lacks the kind of spontaneous autonomy that produces a flash of insight; it is closer to an advanced automation script. To address this, I gave one Agent especially broad authority: my Chief Strategy Mentor thinks and decides with me. Once we have worked from zero to one together, a specialized Agent takes responsibility for the subsequent one-to-many process.
Closing: build your vibe
Concepts are concepts and definitions are definitions; definitions should be yours to make.
Build for your vibe, not for the definition.
If these concepts help you get your work done efficiently, does the name really matter?