DEV Community: Masaaki Hirano

Introducing Perstack: Agentic AI in 12 Lines of TOML, No Framework Required

Masaaki Hirano — Thu, 12 Feb 2026 14:00:00 +0000

Every agent framework I've used buries what the agent does inside the code that makes it run.

Agentic AI -- an LLM looping through tool use, planning, and reflection -- is how tools like Claude Code and OpenClaw operate autonomously. The "agentic" part isn't the model; it's the loop around the model. But in every framework I've tried, that loop is tangled with your application code: HTTP handlers, state management, orchestration. Changing what the agent says means deploying your app. Letting a domain expert tune prompts means giving them the codebase.

I built Perstack to fix this -- an open-source runtime that separates agent definitions from agent execution. The definition is what changes most; it shouldn't be the hardest to change.

The real problem: agents defined in code

Here's what a typical agent definition looks like in a framework:

class SecurityReviewer(Agent):
    def __init__(self):
        self.model = "claude-sonnet-4-5"
        self.tools = [FileReader(), CodeAnalyzer()]
        self.system_prompt = """
            You are a security-focused code reviewer.
            Check for SQL injection, XSS, and auth bypass.
            Explain findings with severity ratings.
        """

    async def run(self, query: str):
        # orchestration logic
        # tool calling logic
        # state management
        # error handling
        # ...

The three lines that actually define what this agent does are buried inside a class that handles how it runs. The behavior and the machinery share a file, a deployment pipeline, and a test suite.

This creates three structural problems:

Framework lock-in. Your agent definition is expressed in the framework's API. Switching to a different runtime means rewriting every agent, not because the behavior changed, but because the packaging did.

Developer-gated iteration. The person who knows the domain -- the security expert, the support lead, the analyst -- can't touch the agent definition without a developer. Prompt tuning becomes a JIRA ticket.

No standalone testing. You can't run the agent without running the app. Feedback loops don't start until the application is wired up. By then, you've invested weeks before discovering the agent doesn't handle edge cases.

12 lines of TOML

Here's the same agent, defined outside the code:

[experts."security-reviewer"]
description = "Reviews code for security vulnerabilities"
instruction = """
You are a security-focused code reviewer.
Check for SQL injection, XSS, and authentication bypass.
Explain each finding with a severity rating and a suggested fix.
"""

[experts."security-reviewer".skills."@perstack/base"]
type = "mcpStdioSkill"
command = "npx"
packageName = "@perstack/base"

Twelve lines. The agent's identity, behavior, and tool access -- all in a single TOML file called perstack.toml. No imports, no classes, no orchestration code.

The instruction field is natural language. The skills section declares tool access via MCP -- @perstack/base is Perstack's built-in tool server, but any MCP-compatible server works (the same standard that Claude Desktop, Cursor, and other tools use). The runtime handles everything else: model access, tool execution, state management, context windows.

This is not a simplification. It's a separation. The agent definition is what changes hourly -- prompts get tuned, tools get added, delegation chains get restructured. The runtime is what changes quarterly. Coupling them in the same codebase means they deploy together, break together, and bottleneck each other.

From idea to running agent

You don't even need to write TOML by hand. create-expert generates it from a description:

npx create-expert "A code reviewer that checks for security vulnerabilities and suggests fixes"

This isn't scaffolding. create-expert is itself an agent that generates the perstack.toml, test-runs the resulting Expert against sample inputs, analyzes the execution, and iterates on the definition until behavior stabilizes. You get a working agent -- not a template.

Run it:

npx perstack start security-reviewer "Review this login handler"

perstack start opens a text-based interactive UI. You see the agent reason, call tools, and produce output in real time. No application to deploy. No environment to configure beyond an LLM API key.

Want headless output for CI?

npx perstack run security-reviewer "Review this login handler"

JSON events to stdout. Pipe it wherever you want.

Multi-agent collaboration in TOML

Experts that need to collaborate? Same file. The delegates field defines which Experts can call which:

[experts."security-reviewer"]
description = "Coordinates security review across the codebase"
instruction = """
Conduct a comprehensive security review.
Delegate file-level analysis to the file-reviewer.
Aggregate findings into a prioritized report.
"""
delegates = ["@security-reviewer/file-reviewer"]

[experts."@security-reviewer/file-reviewer"]
description = "Reviews individual files for security issues"
instruction = "Analyze the given file for SQL injection, XSS, CSRF, and auth bypass vulnerabilities."

The coordinator delegates to specialists. Each Expert runs in its own context window -- no prompt bloat from cramming everything into one conversation. The runtime handles the delegation, result aggregation, and checkpoint management.

From prototype to production

The CLI is for prototyping. For production, Perstack provides lockfile-based deployment and runtime embedding via @perstack/runtime. Execution is event-driven -- every step emits structured events, so it fits naturally into containerized environments where you need to stream progress back to your application. The same perstack.toml drives all of it -- the definition doesn't change because the deployment target changed. The getting started walkthrough covers the full path from CLI to application integration.

Runtime vs. framework: why the distinction matters

Frameworks are opinionated about how you build your application. They provide agent classes, memory abstractions, tool registries, orchestration APIs. Your agent lives inside the framework.

A runtime is opinionated about how agents execute. It doesn't care how your application is built. Your application talks to the runtime over an API. The agent definition is data, not code.

This distinction has real consequences.

Event-sourced execution. Every step the agent takes is recorded as a structured event with step-level checkpoints. You can resume from any point, replay to debug, and diff across model or provider changes. This isn't a logging feature -- it's the execution model. Non-deterministic behavior becomes inspectable.

Isolation by design. Each Expert runs in its own context. Workspace boundaries, environment sandboxing, tool whitelisting. When you deploy to a container platform, the isolation model maps directly to infrastructure -- one container, one Expert, one job.

Independent lifecycles. The agent definition updates hourly. The application code deploys weekly. Environment secrets rotate on their own schedule. User conversations are real-time. A runtime lets these four axes move independently. A framework couples them into one deployment.

Provider independence. Eight LLM providers, one config change. Anthropic, OpenAI, Google, DeepSeek, Ollama, Azure, Bedrock, Vertex. The agent definition doesn't mention the provider.

The methodology shift

The deeper point isn't about TOML syntax or CLI commands. It's about who owns what.

When agent definitions are code, developers own everything. When agent definitions are natural language in a config file, domain experts own behavior and developers own integration. Each side ships on its own schedule. The prompt specialist doesn't wait for a deploy. The developer doesn't review prompt tweaks.

This is the same separation that happened with infrastructure (Terraform), CI/CD (YAML pipelines), and containerization (Dockerfiles). The pattern is: extract the thing that changes most into a declarative format, give it its own lifecycle, and let a runtime execute it.

This separation is overdue for agentic AI.

Perstack is open source under Apache 2.0. The getting started walkthrough covers everything in this article and more. The source is on GitHub.

I'm building this. If the separation between agent definition and agent execution matters to you, I'd like to hear how you're thinking about it.

Prototyping for Agent-First Apps

Masaaki Hirano — Wed, 11 Feb 2026 14:00:00 +0000

When you build an agent-powered app, the instinct is to start with the app — set up a project, install dependencies, write scaffolding. Then somewhere in the middle, you start figuring out what the agent should actually do.

This is backwards.

Agent-first means starting with the agent. Get the brain working first. Once the agent behaves the way you want, expand outward: add tools, then build the shell around it. The agent is the product — everything else is infrastructure.

This matters because the agent will keep evolving. Prompts change, capabilities expand, behavior gets refined. If the agent is tangled with your application code, every change risks breaking something unrelated. Keep the brain separate from the body, and both can evolve on their own terms.

This guide uses Perstack — a toolkit for agent-first development. In Perstack, agents are called Experts: modular micro-agents defined in plain text (perstack.toml), executed by a runtime that handles model access, tool orchestration, and state management. Perstack supports multiple LLM providers including Anthropic, OpenAI, and Google. You define what the agent should do; the runtime makes it work.

Prerequisites: Node.js 22+ and an LLM API key.

export ANTHROPIC_API_KEY=sk-ant-...

What an Expert looks like

An Expert is defined in a perstack.toml file:

[experts."reviewer"]
description = "Reviews code for security issues"
instruction = """
You are a security-focused code reviewer.
Check for SQL injection, XSS, and authentication bypass.
Explain each finding with a severity rating and a suggested fix.
"""

That's the entire definition. No SDK, no boilerplate, no orchestration code. Run it immediately:

npx perstack start reviewer "Review this login handler"

perstack start opens a text-based interactive UI where you can watch the Expert reason and act in real time.

From idea to agent in one command

Writing TOML by hand works, but there's a faster way. create-expert is a CLI that generates Expert definitions from natural language descriptions — it's itself an Expert that builds other Experts.

npx create-expert "A code review assistant that checks for security vulnerabilities, suggests fixes, and explains the reasoning behind each finding"

create-expert takes your description, generates a perstack.toml, test-runs the Expert against sample inputs, and iterates on the definition until behavior stabilizes. You get a working Expert — no code, no setup.

The description doesn't need to be precise. Start vague:

npx create-expert "Something that helps with onboarding new team members"

create-expert will interpret your intent, make decisions about scope and behavior, and produce a testable Expert. You can always refine from there.

Iterate by talking

create-expert reads the existing perstack.toml in your current directory. Run it again with a refinement instruction, and it modifies the definition in place:

npx create-expert "Make it more concise. It's too verbose when explaining findings"

npx create-expert "Add a severity rating to each finding: critical, warning, or info"

npx create-expert "Run 10 tests with different code samples and show me the results"

Each iteration refines the definition. The Expert gets better, and you never open an editor.

Test with real scenarios

Prototyping isn't just about getting the agent to run — it's about finding where it fails.

Write a test case that your agent should catch. For the code reviewer, create a file with a deliberate vulnerability:

npx create-expert "Read the file test/vulnerable.py and review it. It contains a SQL injection — make sure the reviewer catches it and suggests a parameterized query fix"

If the reviewer misses it, you've found a gap in the instruction. Refine and test again:

npx create-expert "The reviewer missed the SQL injection in the raw query on line 12. Update the instruction to pay closer attention to string concatenation in SQL statements"

This is the feedback loop that matters: write a scenario the agent should handle, test it, fix the instruction when it fails, repeat. By the time you build the app around it, you already know what the agent can and can't do.

Evaluate with others

At some point you need feedback beyond your own testing. perstack start makes this easy — hand someone the perstack.toml and they can run the Expert themselves:

npx perstack start reviewer

The interactive UI lets them try their own queries and see how the Expert responds. No app to deploy, no environment to configure beyond the API key.

Every execution is recorded as checkpoints in the local perstack/ directory. After a round of feedback, inspect what happened:

npx perstack log
npx perstack log --tools    # what tools were called
npx perstack log --errors   # what went wrong

You can review specific runs, filter by step, or export as JSON for deeper analysis. See the CLI Reference for the full set of options.

This gives you a lightweight evaluation workflow: distribute the TOML, collect usage, analyze the logs, refine the instruction.

When your prototype grows

At some point, your prototype will need more. The same perstack.toml scales — you're not throwing away work.

The agent needs tools — search the web, query a database, call an API → Extending with Tools
The prompt is getting long — split into multiple Experts that collaborate → Taming Prompt Sprawl
The prototype works — embed it into your application → Adding AI to Your App

What's next

Perstack Repository

The Hell of AI Agent Development

Masaaki Hirano — Wed, 10 Dec 2025 16:19:28 +0000

This isn't engineering. It's prayer.

AI agent development right now is a muddy hell.

The prompt that worked perfectly yesterday lies to your face today.
The framework labeled "cutting edge" will be called "legacy" next week, and its maintainers will disappear the month after.
And the more you look at logs to debug, the more you realize you're wasting your life just trying to guess the LLM's "feelings" instead of checking your logic.

Do you know the web development scene around 2005 where people screamed "Explode, IE!"?
The chaos here makes that look cute.

For the lucky Gen Z devs whose biggest trauma is a React hydration error, let me explain the vibe:

Your model is a moody teenager. It might run your logic, or it might decide to write a poem about strawberries instead. You don't know until you pay the API bill.
Debugging is a gacha game. You pull the lever (run the prompt), spend $0.10, and hope you get a 5-star response (valid JSON). Usually, you get a 1-star trash item (a hallucination).
Documentation is a folklore. The only "docs" are a 6-hour-old tweet from the founder, a Discord channel where everyone is just screaming "LFG", or an undecipherable Arxiv paper written by someone who has never left the lab.

The Definition of "Agent" Died Three Times

On November 30, 2022, ChatGPT appeared, and we all happily jumped into the fire.

2023: The Year of Pointless Optimization
We called them "ReAct." We felt like wizards tuning prompt chains.
We spent hundreds of hours fine-tuning chunk sizes for Vector DBs. We debated "RecursiveRetrieval" vs "ParentDocumentRetrieval" as if it was religious dogma.
We thought we were building assets. We were just building sandcastles that would be washed away by the next model release.

2024: The Year the Credit Card Died
Cline and Manus arrived. The definition changed from "answering a question" to "completing a task."
Great, right? No.
The agent would get stuck in a loop, fixing the same line of code for 4 hours while you slept.
You woke up not to a finished feature, but to a $500 OpenAI bill and a git repo in a detached HEAD state.
We realized "autonomy" often just meant "autonomous money burning."

2025: The Year "Legacy" Became a Daily Event
Computer Use and Claude Code pulled the trigger. Agents now control the browser and terminal directly.
RAG pipelines we built in 2023? Dead.
The custom tool definitions we agonized over in 2024? Dead.
I personally led a heavy RAG project. I spent months optimizing retrieval key-value stores. In one morning update, a model with a massive context window and direct filesystem access turned my life's work into "legacy bloat."
I watched my code rot in real-time. It wasn't just obsolete; it was embarrassing.

Now, top-runner agents rewrite the rules daily. The definition of an agent isn't something you learn anymore. It's something that gets forced upon you while you're trying to fix yesterday's breaking change.

The Reality on the Development Floor

While the industry burns outside, inside the office, we are drowning.

The Client's "Just make it like ChatGPT"
Clients see Sam Altman's tweet and say, "Can we just add this?"
They don't know that the "this" they want requires a complete re-architecture of the agentic loop we spent 3 months building.
The benchmark we targeted 6 months ago is now considered "dumb." You built a calculator; they now want a mathematician.

The "SOTA" Curse
Is the internal tool you built with LangChain in early 2024 still running?
Was that complex CrewAI multi-agent swarm actually better than a single well-prompted Claude 3.5 Sonnet call?
Be honest.
Most of our "cutting-edge" projects from 6 months ago are now just... awkward. Like a flip phone in the iPhone era.

The 95% Failure Rate
MIT says 95% of corporate AI investments fail.
We know why. It's not because the tech is bad. It's because by the time you deploy, the tech is gone.
We are building bridges while the river keeps moving 5 miles downstream every week.
The result is always the same: "Abandon" or "Rebuild." There is no "Maintain."

Prompts Bloat and No One Touches Them

There is also a technical hell.

The funny thing about prompts is that they rot faster than milk in the sun.

You add an edge case here, an XML tag there, and a "please don't hallucinate" prayer at the bottom.
Suddenly, your sleek system instruction looks like a conspiracy theorist's manifesto.
And the LLM? It starts acting like a tired intern on a Friday afternoon. You ask for JSON, it hands you a poem. You ask it to check the docs, it hallucinates a library that doesn't exist. It ignores your all-caps instructions because it got fascinated by a typo in line 400.

But the technical reality is serious. Context Rot.
Research shows the "Lost in the Middle" phenomenon is real. As token count increases, retrieval accuracy drops. The Inverse Scaling Law kicks in.
A 200k context window is meaningless if the effective attention span is only 8k. It is a fundamental trade-off between capacity and precision that no amount of prompt engineering can fully solve.

And then? No one touches that prompt anymore. It becomes "The Sacred Text." It is legacy code, but worse—it's legacy code that costs money every time you run it.

Frameworks: A Bullet Train to the Graveyard

Even more troublesome is framework dependency.

Can you port an agent written in LangChain to Mastra?
No. You're not just porting code; you're rewriting your entire mental model of how an agent thinks. The prompt structure, tool definitions, and memory handling are all tightly coupled to the framework's opinion.

When you uv add an agent framework, you aren't just adding a dependency. You are buying a ticket on a high-speed train with no brakes.
You are determined to die with that framework.
And frameworks do die. Or worse, they "evolve."
How many of you felt a piece of your soul wither away during the migration from LangChain 0.1 to 0.2? We know exactly what "breaking change" means here. It means "rewrite everything or stay on the vulnerable version forever."

Accumulated assets—prompts, tool designs, agent configurations—lose their value along with the death of the framework.

But is that struggle just a developer's problem?

If you switch frameworks, the agent's behavior changes. If you rewrite the prompt, the tone of the response changes. Features that were usable yesterday disappear today due to "spec changes."
From the user's perspective, that might be a "deterioration" rather than an "improvement." Familiar operations suddenly change, and expected responses no longer return.

We developers call it "paying off technical debt." But for users, it's simply "it got harder to use."
Framework convenience, model convenience, development team convenience—everything is passed on to the user experience.
This is the moment when the hell of agent development spreads to the user.

Naturally, we know this risk, so we can't easily make a move.
It is clear that there is a much greater risk of change than when writing REST APIs on a framework.
It's no longer about choosing a framework from a software perspective, but choosing which coffin is comfortable to lie in.

Security? You Mean "RCE as a Service"?

And then there is the production environment. Multi-user. Security.

Let's be honest about what we are building. We are essentially building Remote Code Execution as a Service.

We are giving a probabilistic token generator—which we know hallucinates—the ability to execute shell commands, read files, and access the network.
In any other context, this would be a security nightmare. A critical vulnerability designed by us.
But in 2025, if you don't allow this, your agent is "dumb." If you restrict permissions, it can't do the job.

So you are forced to choose:

Build a Crippled Agent: Safely useless.
Build a Security Time Bomb: Use standard frameworks that run agents inside your app process. One prompt injection, and your server is gone.
Become a Platform Team: Build custom sandboxes, gVisor clusters, and ephemeral VMs just to run a single logical loop.

"Just use a sandbox."
Easier said than done. Are you ready to maintain a complex infrastructure layer just to safely let your agent read a text file?

Is There a Way Out of Hell?

If you've read this far and your eye is twitching, you are not alone.
Welcome to the club. The coffee is stale, the Jira tickets are endless, and the hell is just getting started.

The problem isn't the technology. It's that we haven't agreed on the boundaries.

Remember why IE6 was a nightmare? Because Microsoft tried to bundle the browser with the web.
If you used their browser, you had to use their non-standard tags.
That is exactly what is happening today. Every LLM provider and framework author is trying to verify their own "IE6" ecosystem.

We need to define the "HTML" of agents. We need Separation of Concerns before we all go insane:

Model ≠ Agent: Your logic shouldn't break just because you switched from GPT-5 to Claude 4.5.
Framework ≠ Agent: Your prompts and assets are yours. They shouldn't die just because LangChain released v2.0.
App ≠ Agent: The agent is the worker. The app is just the office. Don't weld the worker to the desk.

We did this for the Web. HTML for structure, CSS for style, JS for logic.
Because we drew those lines, the ecosystem exploded.
Until we draw these lines for Agents, we are just building legacy code on a treadmill. And that is why we are in hell.

Where Are We Heading?

Honestly? The hell will continue until we stop accepting it.

It took 10 years for the Web to get standard HTML5. We are in year 3 of LLMs. We are barely at the starting line.

But history is clear on one thing: Lock-in always loses.
IE died. Flash died. Proprietary walled gardens eventually get demolished by Open Source bulldozers.
The winner isn't decided by Sam Altman or Dario Amodei. It is decided by us.

Every time you choose a framework, you are casting a vote.
Every time you contribute to an open standard, you are building the exit door from this hell.
The ecosystem is shaped by what we use, not what they sell.

So, what can we grassroots developers do?
Actually, we hold all the cards.

Build, Choose, or Speak Up.

If you Build: Isolate.
Write code that doesn't care which LLM it's talking to. Write prompts that don't care which framework runs them. Don't wait for a standard; be the one who creates the boundary.

If you Choose: Resist.
Convenience is the bait. Lock-in is the hook. Don't bite.
Choose tools that let you leave. If a framework demands 100% of your soul, give it 0%.

If you Speak Up: Unite.
Your struggle is not unique. Share your "hell." The only thing proprietary vendors fear is a united developer community saying "No."

It is December 2025. I am still in hell.
But looking around, I see I am not burning alone.

The "Top Runners" are done with their releases for the year. They are probably heading to Hawaii.
We, on the other hand, have hallucinations to debug and breaking changes to fix.

Enjoy the holidays. Try to disconnect.
We have a massive amount of "legacy" code to rewrite in 2026.

See you in hell.

Your turn: What’s your AI agent hell story? Share it in the comments.

MCP Wins, But the War Just Started: Why Standardization Won't Save Us from Lock-in

Masaaki Hirano — Tue, 09 Dec 2025 19:48:06 +0000

December 9, 2025 marked a historical turning point.

Anthropic announced that it has donated its Model Context Protocol (MCP) to the Linux Foundation.
Concurrently, a new management organization, the Agentic AI Foundation (AAIF), has been established under the Linux Foundation umbrella.

This is not merely the transfer of a single technology.
The founding members of this new foundation include not only Anthropic but also OpenAI, Block, Google, Microsoft, and AWS—giant tech companies that should theoretically be competitors.

The chaotic AI industry, where each company had been locking users in with proprietary standards, has finally moved unanimously toward the "standardization of Agentic AI."

The Current State of MCP by the Numbers: Why is it the De Facto Standard?

The momentum of MCP has reached a level that is unstoppable.
Looking at its track record from its introduction a year ago to the present, it is clear why so many companies decided to join.

10,000+: The number of active public MCP servers.
97M+: Monthly downloads of Python and TypeScript SDKs.
Full Adoption by Major Platforms: ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code—virtually all tools used by developers now support MCP.
Immediate Infrastructure Support: AWS, Cloudflare, Google Cloud, and Microsoft Azure officially provide deployment environments for MCP servers.

It is safe to say that MCP is no longer "Anthropic's convenient standard" but has completely permeated as the "plumbing for running AI agents."

Why the Linux Foundation?

The greatest significance of this donation lies in the establishment of Vendor Neutrality.

Until now, no matter how open it was, MCP was "Anthropic's standard." For other companies, betting fully on a competitor's technology that could change specs at any time was a risk.
However, by donating it to the Linux Foundation, MCP has become a "public good" rather than the property of a specific company.

Anthropic itself explicitly stated the reason for the donation: "to ensure that MCP remains open source, community-led, and vendor-neutral."
Future development and maintenance will be determined not by the intentions of a specific company but by community input and a transparent governance model. This is why OpenAI and Google were able to participate with confidence.

AAIF: The Movement for "Agent Standardization" Beyond MCP

In addition to MCP, other critical projects were donated simultaneously to the newly established AAIF (Agentic AI Foundation).

AGENTS.md (Donated by OpenAI): A metadata standard for describing tools and capabilities used by agents. The "instructions for agents," which had been disparate across companies, will now be unified.
goose (Donated by Block): A framework for robust AI agent development.

By managing these under the same foundation, interoperability between tools is expected to improve dramatically. A future where "an agent built with goose reads the specs defined in AGENTS.md and executes tools via MCP" is becoming a reality, even with a mix of different vendors.

Technical Updates: Evolution to Practical Use

Beyond standardization, technical progress has not stopped. The spec update released on November 25 added the following features:

Asynchronous operations: Agents can now proceed without waiting for time-consuming processes.
Statelessness: Reduces the burden of state management on the server side, improving scalability.
Server identity: Enhanced verification of connection legitimacy.
Official extensions: A mechanism to safely extend standard features.

Also, the Claude directory already lists over 75 connectors, and features like "Tool Search" and "Programmatic Tool Calling" via API are becoming robust. A world where "you just plug it in and it works" is right before our eyes.

Conclusion: Will Anything Change?

We are all too familiar with the current state of AI development—a miserable loop where standards proliferate and code becomes obsolete in six months.
Seeing this news, did you think, "This is the end of hell"?

Let me give you the conclusion. Nothing will change. At least, not for now.

MCP has won. The standardization war is over.
However, this merely means the "shape of the power outlet" has been decided. Just because the outlet is unified doesn't mean the power supply becomes stable or the appliances become high-performance.

As Ilya Sutskever mentioned in his podcast "We're moving from the age of scaling to the age of research", we are still squarely in the "Age of Research."
Models are still "Jagged." They are genius at some tasks but make incredibly stupid mistakes at others. This fundamental problem will not be solved just because the protocol has been unified.

The attitude of the vendors won't change either.
They will standardize the troublesome part of "connection," but will then shift all their resources to locking you in with "Intelligence" and "Ecosystems" beyond that connection.

The evidence is clear.
Almost simultaneously with the MCP donation, Anthropic is heavily pushing Agent Skills. This packages procedural knowledge—"how to make the agent behave"—but its execution environment deeply depends on the Claude ecosystem.
On the OpenAI side, Codex has experimentally started similar "Skills" support.

Even more serious is the "Siloization of Troublesome Operations."
Data, runtime, and long-term memory management. These are massive management costs for humans. That's why vendors whisper sweetly, "We'll handle all the messy stuff on the platform side," and actively push for siloization.
Where is the data generated by the agent? The execution logs? The state?
Before you know it, all of it is imprisoned inside a specific vendor's black box, and we aren't even given the key—such a future is steadily being built.

In other words, even if "anything can connect via MCP," the "Brain (Skills)" to use those connected tools wisely will be described in each company's proprietary specs and locked in.
The structure where "the plumbing is common, but the water (intelligence) flowing through it only comes from our faucet" is actually being reinforced.

But we can't blame them.
Fundamentally, the "Agent-first" paradigm shift itself was a nuclear bomb that filled in the vendors' moats.

In the "Human-first" world, the cost of learning a new tool (learning cost) was the biggest barrier. We couldn't switch OSs or leave Office because relearning was a hassle for humans.
But in the "Agent-first" world, it's the agent, not the human, that uses the tool. The agent adapts to the new environment without complaint, hits the API, and completes the task.

By removing the human from the loop, switching costs have effectively become zero.
If "today's strongest model" changes tomorrow, you can switch your entire workflow to the latest intelligence by rewriting a single line in a config file. Now that connection is standardized with MCP, that fluidity is at its peak.

That is precisely why vendors have no choice but to be desperate. If they don't forcibly tie users down with value-adds like "Skills" and "Ecosystems," they will become mere plumbing providers.

Their desperation is the flip side of their fear of becoming "replaceable commodities."

So, the reality in front of us—the pain of prompt engineering, model hallucinations, the battle against non-deterministic behavior—will still be there tomorrow.

DIY GitHub Issue Bot — Just Your LLM API Key

Masaaki Hirano — Fri, 05 Dec 2025 22:01:17 +0000

You've seen those fancy AI bots that answer GitHub issues. Most of them require subscriptions, SaaS accounts, or complex setups.

What if you could build one yourself with just your LLM API key?

With Perstack, you can. Copy two files, add one secret, done.

See it in action: This issue was answered by the bot reading the actual codebase.

📚 New to Perstack? Check out the documentation and getting started guide.

What You Get

An AI bot that:

👀 Reacts to show it's processing
🔍 Actually reads your codebase (not just guessing)
💬 Posts answers with activity logs
💰 Costs only what you use (your LLM API)

Activity log example:

💭 I need to understand how the runtime state machine works...
📁 Listing: packages/runtime/src
📖 Reading: runtime-state-machine.ts
💭 Found the state transitions...
✅ Done

Setup (5 Minutes)

Step 1: Copy Files

Copy from the example repo:

your-repo/
├── .github/workflows/issue-bot.yml   ← workflow
└── scripts/checkpoint-filter.ts      ← formats output

The workflow runs on:

New issue opened
Comment containing @perstack-issue-bot

Step 2: Add Secret

Settings → Secrets → Actions → ANTHROPIC_API_KEY

That's it. Open an issue and watch it work.

Customize It

Want custom behavior? Here's the agent-first development workflow:

1. Create `perstack.toml`

model = "claude-sonnet-4-5"

[provider]
providerName = "anthropic"

[experts."my-issue-bot"]
description = "Custom issue bot for my project"
instruction = """
You are an issue bot for the Acme project.

## Rules
- Always check docs/ directory first
- Add labels: use `gh issue edit --add-label`
  - "bug" for bug reports
  - "feature" for feature requests  
  - "question" for questions
- If the issue is about authentication, mention @security-team
- Keep answers under 500 words
"""

[experts."my-issue-bot".skills."@perstack/base"]
type = "mcpStdioSkill"
command = "npx"
packageName = "@perstack/base"
requiredEnv = ["GH_TOKEN", "GITHUB_REPO", "ISSUE_NUMBER"]

2. Test Locally with `perstack start`

Make sure you have GitHub CLI installed and authenticated.

export ANTHROPIC_API_KEY=your-key
export GH_TOKEN=$(gh auth token)
export GITHUB_REPO=owner/repo
export ISSUE_NUMBER=123

npx perstack start my-issue-bot "Answer issue #$ISSUE_NUMBER"

This opens an interactive TUI where you can watch the bot think, read files, and generate answers in real-time. Tweak the instructions, run again, iterate.

3. Push When Happy

Update the workflow to use your config:

run: npx perstack run --config ./path/to/perstack.toml my-issue-bot "Answer issue #$ISSUE_NUMBER"

Push to your branch, and your customized bot is live.

This is agent-first development — define behavior in text, test interactively, deploy when ready. No code changes, just prompts.

Under the Hood

Why Agent-First Works

The magic is in Perstack's runtime. Your Expert definition — just text in a TOML file — gets executed by the runtime, not compiled into code.

This means:

Same behavior everywhere: Local machine, CI, production — the Expert runs identically
Iterate without rebuilding: Change the prompt, run again, no compile step
Portable: Push to a branch, it just works

The runtime handles everything: connecting to LLMs, managing tool calls, streaming events. You just define what the Expert should do.

Skills & MCP

Experts interact with the world through Skills — MCP servers that expose tools.

@perstack/base provides file ops (readTextFile, listDirectory), command execution (exec), and more. The runtime spins up the MCP server, passes environment variables, and routes tool calls automatically.

[experts."my-bot".skills."@perstack/base"]
requiredEnv = ["GH_TOKEN"]  # Runtime passes this to the MCP server

Event Stream

Everything is observable. The runtime emits JSON events to stdout:

{"type":"callTool","toolCall":{"toolName":"readTextFile","args":{"path":"src/index.ts"}}}
{"type":"completeRun","text":"Here's the answer..."}

Pipe this to a script for real-time UIs, logging, or integration with your systems. See checkpoint-filter.ts for an example.

What's Perstack?

Think npm for AI agents. Define modular agents, publish to a registry, compose them like packages.

No vendor lock-in. No subscriptions. Just your code and your API key.
I'm building this — feedback welcome!

Get started

What is your motivation to use WebComponents?

Masaaki Hirano — Thu, 25 Oct 2018 05:04:51 +0000

If you have already started to write WebComponents code in production/personal use, please let me know what is your motivation to use it.

Because it's standard? Don't want to use react/vue? Or other reason?