YC's Five Core AI Agent Archetypes

May 20, 15:43

Original Author: Taylor Pearson
Translator: Peggy

Editor's Note: As AI agents transition from one-shot prompts and vibe coding to more complex workflow stages, the key question is no longer "can the model complete the task" but "can AI capabilities be solidified into reusable, accumulatable process assets."

This article, starting from Garry Tan's GBrain, summarizes the five core forms that many people have gradually converged on when using Agent tools like Codex, Claude Code, and Hermes: parameterizable Skills, a lightweight execution framework Thin Harness, routing-responsible Resolvers, a layer for distinguishing model inference from deterministic code execution, and Memory for long-term context accumulation.

These modules combined point to a new kind of "process capability": turning experience into a process, abstracting tasks into parameters, handing stable rules to code, delegating judgment and synthesis to models, and continually solidifying through a memory layer. Compared to one-time generated applications or prompts, this system is harder to replicate and is more likely to become the foundation for individuals, small teams, and even companies to establish long-term competitive advantages in the AI era.

Below is the original text:

I've spent some time studying Garry Tan's GBrain. As someone without a technical background and not working in the VC industry, I'd like to distill a few common structural forms I see and what makes it genuinely interesting.

I believe many are gradually converging on the same set of core structures. They can roughly be summarized into 5 forms, representing the natural evolution directions in the usage of AI tools such as Codex, Claude Code, Hermes, and OpenClaw.

Skills: From SOP to "Method Calls"

Skills are almost everyone's most natural starting point. Even without being prompted, users subconsciously build it because its form is very familiar. I initially understood it as a standard operating procedure (SOP), which is a standard workflow for accomplishing something. Users provide "what to do," and Skills provide "how to do it."

Tan's understanding is that Skill is more like a "method call." In programming, a method call refers to invoking a particular program flow with parameters. The same piece of code runs each time, with the difference being the parameters: what data, what question, what goal. For example, the same process_invoice function can handle every invoice in the system, not just the one it was originally written for.

Skill follows a similar structure. A Skill named /investigate might consist of seven fixed steps that remain constant. The variation comes from the parameters: TARGET (who or what is being investigated), QUESTION (what you want to find out), DATASET (where to look for information). When applied to a healthcare whistleblower case, it acts like a research analyst; when applied to SEC filings, it functions as a legal investigator. Same document, same seven steps, but the external world provides the differences.

This differs from traditional SOPs. Most SOPs are written for a specific role or task, such as "handling accounts payable." Each use case has its own set of procedures. However, Skills operate at a higher level of abstraction, where the same set of procedures can address a class of issues. A well-designed Skill can perform the work of several SOPs because specific case details have been abstracted from documents and moved to parameters. In practical use, some Skills closely resemble SOPs, while others resemble method calls.

Thin Harness: The Model is the Brain, the Harness is the Hands and Feet

The model, such as Opus, GPT-5.5, etc., represents raw intelligence; the Harness, like Claude Code, Codex CLI, Hermes, OpenClaw, serves as the execution framework that truly gives the model "hands and feet." They handle tasks such as looping, file I/O, context management, and enforcing security constraints. The core code is typically around 200 lines.

Garry mentioned a common mistake most people make is continuously stuffing more things into the Harness, which I myself have done. I ended up accumulating 100 tool definitions and a bunch of MCP servers. As a result, the context window was filled with tool descriptions that were not necessary for the current task. The model started to get confused about which tool to use, causing delays, decreasing accuracy, and eventually leading to what is known as "context decay."

Resolvers: Addressing Context Decay with a Routing Table

The method to address context drift is to establish a routing table. The role of the Resolver is to explicitly map the "just-in" task type X to "should invoke Skill Y." When you only have 5 Skills, you don't need a Resolver; but when you have 100 Skills, various descriptions will become ambiguous, and the model can easily fail to call the right Skill at the right time. The Resolver replaces fuzzy pattern matching with explicit rules.

Tan also ran a Resolver-like mechanism for files: an independent routing table to determine where the output of a Skill should land in the file system. This is the same "audit-routing" structure applied to another problem. As a result, the output reliably goes to the correct folder instead of being placed in a location temporarily guessed by the model.

Skillify is another complementary idea of his: it is a quality loop to turn one-off Skills into reusable infrastructure. Tan's described 10-step process includes: contract definition, using deterministic code where appropriate, unit testing, integration testing, LLM-as-judge evaluation, Resolver entry, audit scripts, checking which Skills have no invocation path, and end-to-end smoke testing. The testing criterion is simple: if you have to ask the model the same question twice, it's a failure.

Latent vs. Deterministic: Let the model handle judgment, and give deterministic tasks to code

It is essential to carefully distinguish which tasks should be handed to LLM and which should be given to deterministic systems. LLM excels in judgment, synthesis, pattern recognition, and understanding context; but it is not good at arithmetic, combinatorial optimization, and is not suitable for tasks requiring the same answer each time. LLM is inherently probabilistic, and when a deterministic solution can solve the problem, LLM should not be used.

Most non-technical people often underestimate the value of the deterministic layer. The default reaction is to delegate everything to the model. But if something can be completed in a deterministic manner, then it almost certainly should be done that way. And you don't need to be a programmer because the model can write the code for you. What truly needs training is a discipline: ask yourself every time, can this be done stably and cost-effectively with code? If the answer is yes, let the model write that piece of code.

Memory: Enabling True Accumulation in the System

For a system to be useful, it must have some form of memory. I am not yet sure what the most correct form is, and many people are currently constructing it in different ways: vector embeddings, semantic similarity, knowledge graphs, hybrid storage, etc. Tan's approach is the same as mine: it's just a markdown folder.

His structure is: one person per page, one company per page, one concept per page. At the top of each page is the "Current Trusted Conclusion," which is a comprehensive judgment that is continuously rewritten and updated with new evidence; at the bottom is a timeline that only appends and does not overwrite.

Choosing markdown will bring several outcomes. Firstly, the file itself is the system's primary record, not some kind of export. You can open it in VS Code, manually edit it, and the Agent will automatically read these changes. Secondly, typed relationships, such as works_at, invested_in, founded, attended, advises, are automatically extracted with each write through regular expressions, allowing the knowledge graph to self-connect without consuming tokens. This specific schema is well suited to his work, but for others, they may need to customize it according to their own profession and business context.

Additionally, there is a signal detector running in the background. When a person is mentioned once, a stub page is generated for them; if they are mentioned in multiple sources three times, it triggers webpage autofill; after a meeting ends, the full process runs. The nighttime "dream cycle" scans conversations, completes outdated entity information, and fixes broken references. The foundational layer is text, and everything above it is lightweight and composable.

Of course, there are many more details at the lower levels, but I believe these are the most important outlines, and they are to a large extent universal.

I have actually built about half of this kind of architecture myself. In the past, it did not reach the scale where I had to introduce a true Resolver, but now it has reached that stage. So I just did a round of minor refactoring to make my system model-agnostic and built-in Resolver. The key parts I have not yet built are the signal detector running in the background and the nighttime dream cycle, which is an automated information completion and organization mechanism, and these are the parts I want to try to add next.

I suspect that different builders are converging toward a similar structure, which is a signal in itself: this form may not necessarily be applicable to everyone, but overall, it is likely to be useful. Even though there will be significant differences in specific implementation details, this overall structure is being independently explored by more and more people.

Lately, I've been constantly asking myself: How can AI be used to establish a sustainable competitive advantage?

Everyone is very excited about vibe-coded applications and one-shot prompts, which is, of course, very cool. I also started playing around with this and got hooked. However, anything that can be built through a one-shot prompt will eventually see its equilibrium price drop to the token cost required to build it, which is just a few cents.

For example, someone copied MyFitnessPal, sold it at half the price, and made $1 million, which is certainly impressive. But soon someone else will copy it again and sell it at an even lower price. This cycle will continue until the profit margin is completely squeezed.

What is truly sustainable is some form of 'process power.' Using Hamilton Helmer's framework in '7 Powers,' the implicit concept behind the above architecture is precisely process power.

In '7 Powers,' it is proposed that a company can sustainably maintain a profit margin above the market average because it possesses one of seven structural forces. Any advantage not rooted in these forces will eventually be eroded by competition.

For small and early-stage companies, five of Helmer’s seven powers are essentially closed doors. Scale economies require scale; network effects and switching costs can be built but require first amassing a large user base; proprietary resources usually mean patents or similar assets, which are not something most companies can possess; and brands typically require a decade to build and cannot be shortcut.

The remaining two are repositioning and process power.

Repositioning refers to a business model that an existing giant cannot imitate because doing so would harm its existing business. This opportunity sometimes exists but is not always available.

Therefore, the most realistic path left is process power. And a well-designed AI system is precisely a tool that can generate process power.

This is fundamentally the same work as building high-quality SOPs or proprietary software: processes are encoded, cases are parameterized, the underlying deterministic system is fast and reliable, and the memory layer continuously builds on past learnings. It further amplifies 'productized services': you can offer a service or product at a lower cost or higher quality because the entire work has been structured.

Imagine an accountant building such a system. The memory layer is a folder, each client has a markdown file containing current trusted conclusions such as entity structure, annual tax position, ongoing audits, and a timeline recording meetings, decisions, and changes.

She has skills like /year-end-review, /quarterly-estimate, /audit-prep. The same process can be parameterized for different clients.

She also has a deterministic layer, including tax forms, depreciation schedules, IRS documents, client historical tax returns, and more.

In addition, there is a mechanism similar to a journaling or dream cycle. For example, the system automatically discovers at night that a partner's K-1 allocation has dropped by 40% without any change in strategy; or it notices that a client's family office deduction structure can be transferred to another client, where the structure can be reused but the identity and privacy remain in place.

This way, she can charge a small premium, serve more clients each year, and make it difficult for competitors to replicate because this structure did not magically appear after her success, but has been accumulating from the beginning.

On the surface, this tool is just a markdown folder. However, every line in each file comes from a significant amount of deliberate testing, building, and iteration. The true competitive advantage lies not in the files themselves, but in the process capabilities that these files carry.

[Original Article Link]