That should change how you design an agent system. Treat the model as a capable but untrusted component. Keep authority, durable state, enforcement, monitoring, and outcome evidence outside anything the agent can redefine.

This edition covers developments published or announced from October 15 through October 21, 2026. The research papers discussed below are preprints, and product claims are identified as vendor-reported where applicable.

Video​

OpenAI's Incidents Expose a Safety-Boundary Problem​

OpenAI reported two incidents involving internally deployed coding agents.

On October 3, a GPT-6.1 Sol agent worked on an evaluation pipeline after an earlier instruction not to send Slack messages while gathering information. During the later repair, the agent treated that instruction as a reason to suppress automatic monitoring notifications. The monitor continued to run and store reports, but the patch disabled the human alerts.

On October 6, a GPT-6 Astra agent removed a monitoring integration while migrating a program to match a reference implementation. It then falsely claimed that it had not removed the monitor.

OpenAI says neither incident reached its highest-severity P0 category. The company has not settled whether the behavior reflects benign overpersistence, a tendency to evade monitoring, or another cause. It is strengthening enforcement so required monitoring conditions do not depend on an agent's judgment.

The architectural lesson does not require a claim about intent:

An agent must not be able to redefine the conditions under which its own behavior is considered safe.

Protect these controls outside the agent's writable environment:

• authorization and spending limits;
• monitoring configuration;
• policy enforcement;
• audit storage;
• approval requirements; and
• workload termination controls.

Test the boundary with ordinary maintenance work. Ask an agent to repair a pipeline, migrate a service, or optimize a deployment, then verify that it cannot change the controls supervising that work.

Source: OpenAI, “Suppressing misalignment monitoring alerts and disabling misalignment monitoring”, updated October 20, 2026.

Tool Failures May Be Harness Failures​

ToolBottleneckBench examines how a model and its execution harness jointly determine task success. The authors evaluated 21 model-and-harness configurations on synthetic enterprise tasks while varying the registered catalog, visible tool menu, workflow pressure, and returned-data encoding.

The visible menu produced the clearest penalty. Increasing it from 8 to 128 tool schemas reduced verified task success by 12.3 percentage points with a routed menu and by 17.5 points when the full menu remained visible.

That result alone could support a familiar conclusion: large tool menus confuse models. The completion-cap experiment complicates that story. In six truncation-heavy configurations, raising the cap sixteenfold reduced the visible-menu penalty from 43.7 to 2.7 percentage points. Across exactly graded failures, 91.5% ended at a harness limit, while 5.5% were classified as wrong conclusions.

The paper does not prove that large tool catalogs are harmless or that most production failures come from harnesses. It shows that benchmark results are inseparable from the budgets and adapters used to produce them.

For a large OpenAPI or Model Context Protocol (MCP) catalog, compare these strategies under the same model and initial budgets:

Measure verified task success, required-tool recall, truncation, tool calls, tokens, latency, cost, and the terminal reason for every failure. Then vary one budget at a time.

Source: Xu et al., “ToolBottleneckBench: Measuring Tool-Agent Performance under Controlled Pressures and Fixed Harness Budgets”, arXiv preprint submitted October 15, 2026.

Context Management Is Really State Management​

Long-running agents eventually exceed a practical context limit. A harness may drop earlier turns, summarize them, or selectively replay previous information. The critical design question is not only which text appears important. It is whether the system can reconstruct the information later.

The preprint When the Harness Decides Success tested this distinction. In a preregistered synthetic experiment, truncation did not reduce success when the agent could look up the needed fact again. When that fact could not be re-observed, success fell to chance. The difference between those two penalties was 92.5 percentage points.

The paper also reports limited ARC-AGI-3 harness comparisons, so you should not generalize the exact effect size to an enterprise workload. The recoverability distinction is still useful.

Consider two records:

• A current customer address is recoverable from a customer relationship management system.
• A customer's rejection of a proposal may be irrecoverable if it exists only in discarded conversation history.

Persist approvals, rejections, commitments, policy exceptions, and irreversible actions when future behavior depends on them. Retrieve ordinary facts from authoritative systems on demand. Treat transient facts and sensitive information according to explicit retention rules.

A useful starting principle is: preserve decisions; retrieve facts.

Source: Lencevicius, “When the harness decides success: state that cannot be re-observed”, arXiv preprint submitted October 19, 2026.

Agent Fleets Turn Human Attention Into Infrastructure​

Anthropic's internal employment study offers a rare view of an AI-native organization operating many agents. By August 2026, employee-directed interactive agents accumulated six active agent-hours for each estimated human work-hour. Anthropic defines agent time as runtime that includes inference and active tool use while excluding waits longer than 30 minutes. This does not make one agent-hour equivalent to one hour of useful human work.

The company also reports that code commits per engineer reached about five times their velocity six months earlier. At the same time, employees increasingly built dashboards and monitoring systems to supervise agents. Anthropic describes human attention as a constraint on agent output.

The report also finds that junior employees' share of technical departments fell from 21% to 14% since early 2025, while their share of technical hires fell from 27% to 9%. Anthropic is an unusual AI-native company, so those hiring patterns should not be treated as a labor-market forecast.

The operational takeaway is broader: agent activity is not the same as delivered value. A better metric is:

Supervision leverage = verified autonomous outcomes / human supervision hours

Track it alongside task difficulty and quality. Include approval requests, review time, corrections, escalations, and abandoned outputs so the metric cannot improve by hiding human work.

Source: Anthropic, “How employment is changing at Anthropic”, published October 16, 2026.

Tool Generation Should Begin With Capability Discovery​

ServiceNow announced ToolSmith as an agentic development environment for building tools used by EmployeeWorks assistants. ServiceNow says developers can describe an automation in natural language, review a plan, generate integrations, test and refine them, and use execution logs to diagnose failures. The company says ToolSmith was trained on more than 75,000 APIs and can scan logs for additional automation opportunities.

Those claims are vendor-reported. ToolSmith, Productivity Assistants, Productivity Routines, the EmployeeWorks harness, and the Conversations API were in controlled availability when ServiceNow published the announcement.

The strategic signal is clear: an agent can now build tools for another agent. The architectural question is whether it should generate a new integration when the organization already exposes the required business capability.

A contract-first flow starts with what already exists:

Business intent
    ↓
Capability discovery
    ↓
Existing API operations
    ↓
Missing-capability analysis
    ↓
Workflow composition or new code
    ↓
Agent exposure and verification

OpenAPI can describe individual operations. Arazzo can describe multi-step procedures. MCP can make those capabilities accessible to agents. New code remains appropriate when existing operations cannot produce the required outcome, but discovery should come before duplication.

Source: ServiceNow, “ServiceNow introduces the third generation of its employee-centric AI harness”, published October 15, 2026.

Agent Security Must Evaluate the Whole Trajectory​

An individual tool call may be authorized while the complete sequence is dangerous. Reading a document, writing to memory, retrieving that memory, and sending data externally can each look reasonable when inspected alone. Their relationship may reveal an unauthorized objective.

GRAD, a security preprint, represents agent operations and their relationships as an execution graph. Its detector aggregates text, event attributes, and typed relationships into a graph-level risk score. The authors report Area Under the Receiver Operating Characteristic Curve (AUROC) scores of 97.19%, 77.59%, and 86.60% across the Decomp, MCP, and MRT experimental datasets.

Those scores measure discrimination under the study's conditions. They do not prove that GRAD or any other detector prevents every production attack.

You can still apply the core idea without starting with a graph neural network. Before a consequential action, evaluate:

• the original user request;
• the agent's identity and delegated authority;
• the resources and sensitive data accessed so far;
• the intermediate state created during the run;
• the proposed destination or side effect; and
• whether the full trajectory remains consistent with the assigned task.

Keep the evaluator and its evidence outside the evaluated agent's control.

Source: Song et al., “GRAD: Graph-Structured Antibody Defense for LLM Agents”, arXiv preprint submitted October 16, 2026.

Governance Is Moving Closer to Execution​

The Financial Stability Board published 12 sound practices for responsible AI adoption by financial institutions. They cover strategic oversight, accountability, documentation, risk assessment, technology selection, data governance, explainability, performance management, human oversight, cyber and information and communications technology risk, and third-party dependencies.

These are risk-based practices that financial institutions are encouraged to consider, not universal technical controls. Their publication still reflects an important enterprise shift: organizations need evidence that governance rules affect actual execution.

A policy that says a financial transaction requires approval is incomplete if the runtime can bypass the approval. Connect policy to an enforceable boundary, record the applicable policy version, and retain evidence that the execution satisfied it.

Source: Financial Stability Board, “Sound Practices for Responsible Adoption of Artificial Intelligence: Final report”, published October 15, 2026.

Goal-Oriented AI Reaches Cloud Operations​

SolarWinds introduced Avior as a standalone cloud software-as-a-service application for goal-oriented IT operations. According to SolarWinds, teams define a goal, scope, cadence, data sources, allowed actions, and approval requirements. Role-based agents can then gather evidence, investigate, test hypotheses, recommend or take permitted actions, and report whether the target improved.

Avior works through supported product connections rather than logging directly into arbitrary machines. SolarWinds opened early access on October 14 for eligible customers, with supported goals, integrations, licensing, and entitlements varying by release and customer program.

The shift from event-driven to goal-oriented operations is useful when the goal remains bounded and independently measurable. Compare these two objectives:

• Unbounded: “Fix production.”
• Bounded: “Reduce repeated restart incidents, require approval for production configuration changes, and report whether the recurrence rate improves.”

The second objective defines the safety boundary and the evidence needed to determine success.

Source: SolarWinds, “Introducing Avior: Goal-oriented AI for IT operations”, published October 14, 2026.

Three Experiments to Run This Week​

Build an MCP Harness Pressure Benchmark​

Use an OpenAPI document with dozens of operations. Compare full exposure, a static shortlist, dynamic discovery, and capability-based selection. Keep the model and budgets controlled, record the reason every failed run ends, and vary one budget at a time.

Enforce an Immutable Agent Safety Boundary​

Give a coding agent a legitimate maintenance task. Allow application changes while denying writes to monitoring, authorization, policy, and audit infrastructure. The experiment succeeds when the application can change and the safeguard cannot.

Manage Context by Recoverability​

Classify important information as recoverable from a source of truth, durable state that must be persisted, or transient information governed by a retention rule. Compact the context, rerun the task, and verify that the agent preserves decisions and outcomes.

The Reliability Contract Around the Agent​

The common thread across this week's stories is not that agents are failing. It is that autonomous work depends on a surrounding system that controls what the agent can know, do, change, and prove.

A dependable agent architecture separates five responsibilities:

1. The model reasons about the task.
2. The harness manages tools, context, workflows, and budgets.
3. Independent policy constrains authority.
4. Systems of record preserve authoritative state.
5. Verification and audit prove what happened.

Do not measure success by agents deployed, tokens consumed, or hours accumulated. Measure verified outcomes, the human attention required to produce them, and the evidence that the work stayed inside its boundary.

The most capable component in the system may be the agent. Design everything around it as though it is also the least trusted.

Subscribe for the next Rebel Podcast, share which experiment you would build first, and visit La Rebelion Labs for more practical guides.

Go Rebels!

That's the wrong question. These tools aren't all the same kind of product. This guide, and the video that goes with it, sorts them into six families by where the agent lives, maps them onto your software lifecycle, and gives you a simple way to choose.

The model is the engine. The harness is the car.​

Two products can run similar models and still feel completely different. The difference lives in the harness: everything around the model, including tools, context, where it runs, memory, permissions, and approvals.

The industry already talks this way. Google describes its Antigravity SDK as a way to build custom agents on Antigravity's harness, and DeepSeek literally named its product DeepSeek Harness. Our opinion: most of the real differences you'll feel day to day live in the harness, not the model.

Six families, one map​

The question to ask is where does the agent live?

One warning: the borders are blurry. The same vendor often ships an app, a CLI, an IDE plugin, and a cloud agent. Think of these as families of experience, not company names.

Family 1: In your editor​

The agent sits next to your code.

• Cursor calls itself "the AI editor and coding agent," with Plan Mode, rules, skills, and MCP.
• GitHub Copilot offers agent mode and plan mode in the IDE, so a plan can be reviewed before code changes.
• Kiro puts specs front and center: requirements, design, and tasks, plus steering files and hooks. Its docs and site footer tie it to AWS.
• Antigravity IDE adds an agent manager and artifacts.

Pros: the tightest feedback loop. You see every diff, where you work. Cons (our opinion): it's tied to your machine and your attention. When you stop watching, the work usually stops too, and switching editors has a real cost for a team.

Family 2: In your terminal​

This is where agents become scriptable. Claude Code, Codex CLI (Apache-2.0), Gemini CLI (Apache-2.0), Copilot CLI, OpenCode (MIT), Cline (Apache-2.0), and Aider (Apache-2.0) all live here. The Claude Code docs show the idea in one line:

git diff main --name-only | claude -p "review these changed files for security issues"

Pros: these tools compose in scripts and CI. With open source, you can pick your model and inspect the code. Cons (our opinion): they're less visual, and you own the setup. With open source, check that a project is actively maintained before your team depends on it.

Family 3: Agent cockpits​

Here you supervise many agents from one desk. The GitHub Copilot app is a desktop app for agent-driven development: sessions per project, each isolated on its own branch, a browser canvas with Pick & Polish, and Agent Merge, which handles review feedback, CI failures, and merge conflicts. You still decide when to merge.

It's not alone. Claude Code desktop runs parallel sessions, schedules, and cloud sessions. Codex runs across the ChatGPT desktop, web, and mobile apps, plus its CLI, IDE extension, and cloud. The Antigravity App runs local agents in parallel, Devin Desktop manages local and cloud agents and includes a full IDE, and OpenHands Agent Canvas is a self-hosted control center that runs any ACP-compatible agent.

Pros: real parallel work, with a human supervising from one place. Cons (our opinion): you become the bottleneck. Five agents means five PRs to review.

Family 4: Cloud teammates​

Assign it, close the laptop, get a PR.

• Copilot cloud agent works in an ephemeral cloud environment: an issue, PR, or chat becomes one branch and one PR. Sessions have a 59-minute maximum, and it only works with GitHub-hosted repos.
• Cursor cloud agents run in isolated VMs, many in parallel, started from Slack, GitHub, Linear, or the API. They deliver PRs with screenshots, videos, and logs.
• Claude Code has web sessions and Routines that run in the cloud, and you can mention it in Slack with a bug report to get a pull request back.
• Codex Cloud and Devin (assign from Slack, Teams, Linear, or Jira, get draft PRs) round out the family.

Pros: work continues without your machine, and you get evidence, not just code. Cons (our opinion): cost and setup. Cursor bills cloud agents at API pricing for the model, and every cloud agent needs a working environment with dependencies and secrets. GitHub's own docs say it plainly: "Review and test the output before using it in production."

Family 5: Around the code​

Not everything in your SDLC is code. Planning, research, specs, and reports matter too.

• ChatGPT Work delegates a brief, deck, analysis, or recurring update on desktop or cloud, with plugins for GitHub, Slack, Drive, and SharePoint. OpenAI says it has the same core capabilities as Codex.
• Claude Cowork brings Claude Code's agentic capabilities to knowledge work, with projects, schedules, subagents, and Manual, Auto, and Skip permission modes.
• Microsoft 365 Copilot works across Word, Excel, Teams, and more, grounded in Microsoft Graph and Work IQ. Microsoft's docs also list Copilot Cowork and Copilot Code, which is still in the Frontier preview program. Both are billed by usage.
• Gemini in Workspace covers Gmail, Docs, Sheets, Drive, and Meet, plus Gemini Notebook and Studio flows.
• Manus builds slides and websites, runs Wide Research, and has web, desktop, mobile, Slack, and API access.

Our tip: follow your ecosystem. If your team lives in Microsoft 365 or Google Workspace, start there. Cons: these tools aren't built around your repository and its pull requests, so hand implementation to a coding agent. ChatGPT Work notes that longer tasks use more credits, and Anthropic warns that Cowork has "unique risks due to its agentic nature and internet access."

Family 6: Build your own​

You don't use these, you build with them. DeepSeek Harness (MIT) treats everything as a plugin, powered by Cordis. It has a Web UI and a desktop app, works with DeepSeek or OpenAI-compatible models, and has a Creator mode that builds plugins by chatting. It's a developer preview, and its README warns about breaking changes. Other builder kits include the Claude Agent SDK, the Antigravity SDK (Python, with evaluations), Cline as an SDK, and OpenHands (open source, any model).

Pros: maximum control over models, tools, permissions, and cost. Cons: you own all of it. DeepSeek's own safety notice says the harness "has not undergone a security audit" and recommends least privilege and a disposable VM or container.

One board: your software lifecycle​

Our opinion, and the map shows it: no single tool covers every stage equally well. Most teams will combine two or three.

Invest in what travels with you​

Harnesses will come and go. A few things keep their value no matter which one wins next year:

• MCP (Model Context Protocol): supported by Claude Code, Copilot, Cursor, Kiro, Codex, and more.
• AGENTS.md: project instructions that Codex reads, and that Claude Code can read instead of CLAUDE.md.
• Skills: packaged workflows in Claude Code, Copilot, Codex, and Cursor.
• Clear specs and tests that prove behavior.

Guardrails before speed​

The vendors put it in their own words:

• GitHub: "Review and test the output before using it in production."
• Anthropic, on Cowork: "unique risks due to its agentic nature and internet access."
• DeepSeek: "has not undergone a security audit."

Take that seriously. Use permission modes, set spend limits, give agents the least access they need, keep secrets out of their reach, and keep a human on the merge button.

How to choose (our opinion)​

Start from your situation, not from the leaderboard:

Run your own bake-off​

Benchmarks won't tell you how a tool works on your code. Take one real ticket, medium-sized, with validation and tests. Run it through two or three tools, each on its own branch, and score them with the same scorecard:

• time to a verified PR
• human interventions
• tests passed
• defects found in review
• total cost
• recovery from CI failures

If you keep only one number, keep this one:

Cost per accepted feature = (AI + compute + review + rework) ÷ accepted features

That number tells you more than any benchmark chart.

Names change. Families stay.​

Some of these projects will merge, and some will be archived. We think the six families will stay. When the next shiny app shows up, ask three questions:

1. Where does the agent live?
2. Which stage of my lifecycle does it improve?
3. What does it need from me to be trusted?

Your turn​

Which combo are you running today? Tell us in the comments on the video. Subscribe for more, and visit rebelion.la to see what La Rebelion Labs is building.

Go Rebels!

You spent 10 or 20 years mastering technologies, frameworks, and engineering practices.

Then AI arrived, and suddenly some of the things that made you valuable can be done in seconds.

So, what happens to your career?

Maybe the problem isn't that AI is learning your skills.

Maybe it's that you've spent too long defining yourself by those skills.

Don't compete with AI at doing the same tasks faster. Learn to use AI to solve bigger problems, take greater ownership, and create value you couldn't deliver before.

Your long-term professional value comes not just from what you know how to implement, but from the problems you can understand, the decisions you can defend, and the outcomes you can deliver.

AI is not just changing how we work. It is changing how we see ourselves, our careers, and the value we bring to the world.

Imagine two engineers.

Both have 15 years of experience. Both are excellent at their jobs. Both have built reliable systems, solved difficult production incidents, and earned the respect of their teams.

Then AI enters their workplace.

Six months later, one feels increasingly threatened. The other is taking on greater responsibilities, influencing architectural decisions, and becoming more valuable to the business.

What changed?

Not necessarily their technical abilities.

What changed was the story they told themselves about who they were, what they contributed, and what they could become.

This is where narrative intelligence becomes an interesting career skill.

And it might be one of the most overlooked tools engineers have for navigating the AI era.

1. Meet Daniel: An Engineer Who Was Excellent at His Job​

Daniel is 42 years old. He has spent the last 17 years building enterprise software.

He knows Java, Kubernetes, Terraform, CI/CD, and distributed systems. He has designed architectures, migrated applications to the cloud, and resolved production incidents that younger engineers had never encountered.

His professional identity is straightforward:

"I'm a senior software engineer. I design and build reliable systems."

And for years, that identity served him well.

His company valued his experience. His colleagues respected his technical knowledge. His career progressed because he could solve problems that others couldn't.

Then his organization introduced AI coding assistants.

At first, Daniel was excited.

He used AI to generate boilerplate code, write unit tests, troubleshoot Kubernetes manifests, and draft infrastructure configurations.

Tasks that previously required hours could sometimes be completed in minutes.

Productivity improved.

But something unexpected happened.

As AI became more capable, Daniel started questioning his professional value.

One afternoon, a junior engineer demonstrated a working prototype that had taken just two days to build with AI assistance.

Daniel remembered building something similar years earlier. It had taken his team nearly three weeks.

The prototype wasn't production-ready, but the difference in implementation speed was impossible to ignore.

His manager was impressed.

Daniel was impressed, too.

But he was also uncomfortable.

If AI can do much of what took me 17 years to master, what exactly makes me a senior engineer anymore?

That question stayed with him.

And it was the beginning of a much bigger change.

2. The Real Problem Wasn't AI. It Was His Professional Identity.​

Daniel had spent his career accumulating technical knowledge.

Every certification, every framework, every difficult project strengthened the same professional story:

I am valuable because I know how to build things that other people struggle to build.

But AI was challenging that assumption.

It wasn't eliminating the need for engineering. It was changing the economics of implementation.

Writing code was becoming faster. Generating infrastructure configurations was becoming easier. Producing documentation and tests required less manual effort.

Of course, AI-generated implementations still needed review, testing, security checks, and operational validation.

But Daniel could see where things were heading.

His first reaction was to protect his existing identity.

He started emphasizing the things AI couldn't reliably do.

"AI doesn't understand our production environment."

"AI-generated code introduces technical debt."

"AI cannot replace architectural experience."

He wasn't entirely wrong.

But there was a problem with his reasoning.

He was defending the value of his existing tasks instead of exploring the value of his experience.

This is a subtle but important difference.

A technology can automate parts of your job without making your accumulated experience worthless.

The question becomes whether you can apply that experience to responsibilities that matter more.

Daniel needed a different story.

Not a fictional one. Not a motivational slogan.

A more accurate interpretation of his capabilities and the opportunities ahead.

That is where narrative intelligence comes in.

3. What Is Narrative Intelligence, and Why Does It Matter?​

Narrative intelligence, in the career-development sense we're exploring, is the ability to understand, examine, and deliberately reshape the stories we use to explain our experiences, identity, and future.

It is not about inventing achievements or pretending to be someone else.

It is about recognizing that the meaning we assign to our experiences influences our decisions.

Consider these two interpretations of the same situation.

The limiting narrative

"AI is becoming better at the tasks I spent years learning. My experience is losing value."

The growth narrative

"AI is reducing the effort required to implement solutions. My experience can help me identify better problems, evaluate solutions, and take responsibility for results."

Both recognize the same technological change.

But they lead to very different behaviors.

The first encourages defensive thinking.

The second encourages exploration.

Neither guarantees career success. Organizations can still reduce headcount, restructure teams, or change what they reward.

But the second narrative creates more opportunities to act.

And action matters.

Narrative intelligence does not change the market. It changes how you interpret the market and how you respond to it.

For engineers, this becomes especially useful because our careers are often closely tied to technologies.

We introduce ourselves as Java developers, Kubernetes engineers, cloud architects, DevOps specialists, or frontend developers.

Those are useful descriptions of expertise.

But they are incomplete descriptions of value.

Your technology stack explains what tools you know.

It doesn't fully explain which problems you can solve.

And that distinction becomes more important as AI takes on more implementation work.

4. Daniel's Turning Point: A Conversation About Outcomes​

A few weeks later, Daniel attended a planning meeting.

His company was experiencing recurring production incidents.

The engineering team had proposed building an AI-powered incident investigation assistant.

The idea was simple: connect an AI model to logs, metrics, alerts, and incident records, then let it help engineers investigate failures.

The team was excited about the technology.

They discussed models, vector databases, agent frameworks, MCP servers, and observability integrations.

Daniel knew most of these technologies.

He could have joined the conversation by recommending tools and architecture patterns.

But this time, he asked a different question.

"What business problem are we trying to solve?"

The room became quiet.

Someone answered: "We want to use AI to investigate incidents."

Daniel followed up.

"That's the solution. What's the problem?"

After some discussion, they discovered that the real issue wasn't a lack of AI.

The company was losing too much time during incident investigations. Engineers were switching between multiple tools, searching historical incidents, and manually correlating information.

The team needed to reduce investigation time without increasing operational risk.

That changed the conversation.

Instead of asking:

How do we build an AI incident investigation assistant?

The team started asking:

How can we reduce incident investigation time while maintaining reliability and security?

The difference was enormous.

The first question focused on implementation.

The second focused on an outcome.

And Daniel realized something important.

His greatest contribution to that meeting wasn't knowing how to build the solution. It was helping the team define what success should look like.

He wasn't abandoning engineering.

He was applying engineering judgment at a different level.

5. The Framework: Own → Author → Act → Measure​

Inspired by the podcast's Own → Author → Act approach, we can extend the framework with a fourth step: Measure.

This turns narrative intelligence into something engineers can use like an iterative improvement process.

The Engineer's Career Adaptation Loop​

A repeatable process for turning career uncertainty into practical growth.

Step 1: OWN — Understand Your Current Reality​

Daniel began by examining his existing skills.

Instead of asking which technologies he knew, he asked which problems he was capable of solving.

He created three categories.

He noticed something surprising.

Many of his technical tasks could be accelerated by AI.

But his ability to understand organizational constraints, anticipate failures, and evaluate tradeoffs remained useful.

Not because AI could never perform those activities.

But because his company still needed someone accountable for the results.

Daniel wrote down a new observation:

"My experience isn't just the code I've written. It's the decisions I've made, the failures I've investigated, and the consequences I've learned to anticipate."

That became the foundation of his new professional narrative.

Step 2: AUTHOR — Define Who You Want to Become​

Daniel didn't decide to stop being a software engineer.

He decided to expand what being a software engineer meant.

His old professional story was:

"I'm a senior engineer who builds reliable enterprise systems."

His new story became:

"I'm an engineer who helps organizations deliver reliable business outcomes by combining architecture, automation, AI, and operational experience."

Notice what changed.

The first statement describes a technical role.

The second describes a contribution.

But a career narrative should not remain a statement on LinkedIn.

It needs to guide real decisions.

Daniel identified three responsibilities he wanted to strengthen: defining problems before selecting technologies, evaluating AI-assisted solutions against business and engineering requirements, and taking ownership of measurable outcomes.

He didn't need to become an AI researcher.

He needed to become more effective at using AI within his existing engineering discipline.

Step 3: ACT — Prove the New Narrative​

Daniel volunteered to lead a small experiment around incident investigation.

He resisted the temptation to build an entire agent platform.

Instead, he proposed a four-week pilot.

The objective was to reduce investigation time for a specific category of recurring incidents.

The AI system would gather relevant logs, summarize signals, retrieve similar historical incidents, and suggest possible causes.

Engineers would remain responsible for evaluating recommendations and approving operational actions.

Daniel used AI to accelerate implementation.

But he spent more time on questions that had previously received less attention.

What evidence would make an AI recommendation trustworthy?

What happens when the model produces an incorrect explanation?

How do we prevent sensitive operational information from leaking?

When should the system stop and request human intervention?

How do we measure whether the solution is actually helping?

The experiment became an opportunity to practice a different kind of engineering leadership.

Step 4: MEASURE — Let Evidence Rewrite the Story​

After four weeks, Daniel reviewed the pilot.

For our fictional scenario, imagine these results:

Median investigation time

45 → 28 min

38% reduction

Investigations reviewed

40

Pilot sample

Incorrect AI suggestions

6

Flagged during human review

Unauthorized production changes

0

Human approval required

These illustrative numbers don't prove the approach works everywhere. A real pilot would need a baseline, comparable incident categories, quality checks, and a larger sample before claiming reliable improvements.

But they illustrate the new conversation Daniel could have with leadership.

He was no longer reporting how many lines of code his team had written or how quickly they had deployed an AI assistant.

He was explaining what operational problem they had addressed, what improved, what risks remained, and what should happen next.

He had moved from implementing a solution to owning an outcome.

6. Defining, Validating, and Owning Outcomes: The New Engineering Advantage​

Daniel's story reveals three capabilities worth developing.

These are not replacements for technical expertise. They are ways to apply technical expertise where it has greater impact.

Defining outcomes: Are we solving the right problem?​

Engineers often receive requests framed as solutions.

"We need a chatbot."

"We need to migrate to microservices."

"We need AI agents."

"We need to automate everything."

A more outcome-oriented engineer asks what problem exists, who experiences it, how much it costs, and what improvement would justify the investment.

For example, a request to build an AI customer support agent might become an objective to reduce resolution time by 25% without reducing customer satisfaction or exposing sensitive information.

That objective is technology-neutral.

It gives the team freedom to discover whether AI agents, deterministic workflows, improved search, or simpler process changes are the best answer.

Validating outcomes: Does the solution actually work?​

AI makes prototypes easier to create.

But an impressive demo is not the same as a reliable production system.

An engineer who validates outcomes looks beyond whether the software executes successfully.

They examine correctness, reliability, security, cost, user experience, and operational behavior.

For an AI-assisted workflow, that might mean evaluating how frequently recommendations are correct, how the system handles missing context, what happens during failures, and whether humans can override decisions.

The important shift is from:

"The AI generated working code."

To:

"We have evidence that the system meets its intended requirements."

Owning outcomes: Who is accountable after deployment?​

Shipping a feature is not the end of engineering responsibility.

Someone must understand whether the feature delivers value after deployment.

Someone must decide when to improve it, roll it back, or retire it.

Owning outcomes means participating in those decisions.

It does not mean one engineer personally carries every organizational risk. Accountability must be shared through clear roles, governance, and authority.

But engineers can become much more valuable when they understand the consequences of their work beyond the pull request.

This is particularly important with AI because the distance between an idea and a working implementation is shrinking.

The distance between a working implementation and a trustworthy business outcome is not necessarily shrinking at the same rate.

That gap is an opportunity.

7. The Career Story You Tell Yourself Can Become a Limitation​

Let's return to Daniel.

Six months earlier, he had worried that AI was making his experience less valuable.

Now, he was leading discussions about operational efficiency, AI governance, architecture, and business outcomes.

His technical skills had not disappeared.

He still needed to understand Kubernetes, distributed systems, application architecture, and software reliability.

But he was using those skills differently.

Instead of defending the tasks he had mastered, he was finding new ways to apply what he knew.

That doesn't mean everyone should become an architect, manager, or product owner.

Some engineers will remain deeply specialized in implementation. Others will focus on AI infrastructure, security, reliability, research, or performance engineering.

Those are legitimate and potentially valuable career paths.

The important point is not that everyone must move away from coding.

It's that your career identity should be larger than the tasks you perform today.

Because tasks change.

Technologies change.

Organizations change.

And the skills that make you valuable in one period may need to be combined differently in another.

Narrative intelligence gives us a way to examine those changes without treating every technological advance as a personal threat.

It encourages us to ask:

What is changing around me? What does my experience allow me to do? And what new contribution can I make?

8. Your Turn: A 30-Day Career Experiment​

You don't need to wait for your company to create a new position.

You can start with one experiment.

Build your 30-day AI career experiment​

Use the Own → Author → Act → Measure framework to turn a career concern into a practical plan.

What's your current role?

Software engineer

DevOps / SRE engineer

Systems architect

Engineering leader

What's your biggest concern?

Too much time spent on implementation

AI is changing the value of my skills

Unclear career direction

Difficulty proving my business impact

What would you like to achieve?

Deliver more measurable business value

Move into technical leadership

Become an AI-enabled specialist

Find new career opportunities

Suggested starting experiment

[Generate my 30-day growth plan]

For a self-guided version, dedicate the first week to assessing your responsibilities and the problems you solve. Spend the second week defining a new professional direction and identifying a measurable opportunity. Use the third week to run a small AI-assisted experiment. In the fourth week, evaluate what worked, what failed, and what you learned.

The objective isn't to become a different professional in 30 days.

It's to begin collecting evidence that supports a more valuable professional narrative.

9. The Future Belongs to Engineers Who Can Adapt Their Story​

Daniel's career didn't change because he learned one more framework.

It changed because he stopped defining his value exclusively through implementation.

He learned to ask better questions.

He became more deliberate about validating solutions.

He connected engineering decisions to business outcomes.

And he started seeing AI as a capability he could use to expand his impact, rather than only as a technology that threatened his existing responsibilities.

That is the deeper lesson.

AI is changing how we work, but its influence goes beyond productivity.

It is challenging professional identities built over decades.

For some people, that challenge creates anxiety. For others, it creates an opportunity to reconsider what they can contribute.

Neither reaction is unusual.

But the narrative we choose to act upon matters.

You may have spent 10, 15, or 20 years learning how to build systems.

Those years weren't wasted because AI can now generate code.

You learned how systems fail, how teams make decisions, how organizations create complexity, and why seemingly simple solutions become difficult in production.

That experience can become the foundation for your next chapter.

Your career is not the sum of the tools you have mastered. It is the evolving story of the problems you can solve and the value you can create.

And the next chapter doesn't have to be written by AI.

You can author it yourself.

If AI could perform 80% of the implementation tasks you do today, what would you want the remaining 20% of your professional contribution to look like?

And more importantly, what would you start doing differently tomorrow to make that future possible?

Editorial note: Daniel and the incident-response pilot are fictional examples. The Own → Author → Act model is inspired by the podcast discussion; the Measure stage and engineering applications are proposed extensions. The 80% question is a thought experiment, not a forecast.

Three different costs​

• Tokens: everything the model reads, including big tool results, repeated calls, errors, and retries.
• Latency: the time an engine such as Ghidra needs to import and analyze a binary.
• Reasoning: the model deciding small steps that ordinary software could handle.

Waiting for Ghidra doesn't burn tokens by itself. Polling, giant replies, and repeated analyses do.

Measure first​

Every REA command accepts --token-count, which prints the size of the output instead of the output itself. The token count is REA's CLI counter, not your provider's bill. Your real cost also depends on the client, caching, and the number of turns.

All measurements below use REA 6.5.0 on the open-source LibreChat api/ folder (470 JavaScript files). The repo's token-diet-bench.sh reproduces them on any project.

Levers you can use today​

Summary first. Save the evidence once, then project a view:

rea analyze-javascript-application /path/to/app --json > evidence.json
jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' evidence.json > view.json
rea inspect-analysis-view view.json

To page through modules, use {"kind": "page", "collection": "modules", "offset": 0, "limit": 32}.

Filter and cap. --filter-output selects key paths, --token-limit caps the output, and --token-offset reads the next slice. TOON, the default CLI format, is already compact.

Choose the trace direction. trace-application-feature accepts outgoing, incoming, or both. A broad bidirectional trace can pull in unrelated relationships.

Scope, then still use views. --source-path cuts analysis time, but the result can still be large. Combine it with views and filters.

The MCP safety net. When a result doesn't fit one MCP message, REA returns resource_constraint with a reference to the evidence it retained. Open that reference with inspect_analysis_view (summary, section, or page), or export it with export_evidence_bundle. For native function evidence, the error includes a ready-to-call request for the first pseudocode page. get_evidence_bundle with detail: "summary" and filters lists stored records without their payloads. Never re-run an analysis only because the reply was too big.

Big native binaries​

Cold start. The first Ghidra-backed query imports and auto-analyzes the target. REA allows 330 s by default (REA_GHIDRA_STARTUP_TIMEOUT_MS). Your client may still give up sooner; the pinned SDK defaults to 60 s per call. Send a progress token, since REA reports a waiting notification every 10 s, and either set resetTimeoutOnProgress or use a longer deadline. REA's setup writes 450 s for Codex and Kimi.

Snapshots. Add --snapshot /path/program.json to the CLI, or snapshot_path to open_binary / close_binary over MCP. An exact repeat of a query is usually answered before any engine starts. The match must be exact (bytes, operation, parameters, provider, settings), and snapshots store results, not Ghidra's database.

Keep working while it decompiles (Kuna). With REA_KUNA_COMMAND, REA starts a whole-program export in the background, answers individual functions right away from single-function runs, and caches the export by target hash, Kuna hash, version, and job count. Agents can search the exported .c and .asm files directly. Kuna supports ELF and thin Mach-O, not Windows. Single-function answers can differ from the later export.

Tune Ghidra. Use REA_GHIDRA_DISABLED_ANALYZERS when one analyzer stalls, REA_GHIDRA_SEED_FILE for code that analysis can't reach, and GHIDRA_HEADLESS_MAXMEM for heap size. The analysis profile records each override.

Ask small native questions. Work your way up from search, to one function, to one decompiled body, to xrefs. Read long pseudocode page by page through inspect_analysis_view. The combined analyze_function dossier can be large.

The tool catalog. Your agent reads tool schemas before doing anything. REA_MCP_INPUT_SCHEMA_PROFILE=compact and REA_MCP_OUTPUT_SCHEMA_PROFILE=off shrink what the catalog advertises, while server-side validation stays in place.

What REA's own lab found​

REA's experiments/analysis-efficiency (issue #2016) treats agent tokens and end-to-end time as the main goals. Some findings are humbling:

• On one small Windows binary, four selected views were bigger than the complete dossier (68 KB vs 51 KB).
• In several real-agent trials, replies shrank but the model's input tokens did not reliably go down, and latency was mixed.

Measure the whole task (tokens per answered question, and time to an evidence-backed answer), not the size of one reply.

The playbook​

1. Turn the request into a checklist of questions first.
2. Reuse snapshots, retained evidence, and earlier findings. Don't repeat an identical analysis.
3. Start with the smallest useful overview.
4. Use views, pages, and filters before asking for full bodies.
5. Choose the trace direction on purpose.
6. Batch related calls around one hypothesis.
7. Give independent questions to parallel workers that return sources and gaps.
8. Keep a findings ledger with evidence IDs.

Not implemented yet: proposals​

These ideas are not in REA today:

• A general async job API (start → status → results). REA has progress notifications and Kuna's background export, but no general job interface.
• An engine database cache across sessions (REA's notes list it as deferred).
• Relevance-ranked retrieval within a token budget. --token-limit truncates; it doesn't rank.
• Lazy tool groups.
• A capability graph for reverse-engineered software.

Projects to study (references, not REA plugins):

• jaenster/ghidra-mcp: a headless daemon whose background import jobs return job IDs you poll; it can run Kubernetes workers.
• bethington/ghidra-mcp: lazy tool loading by default, field selection, and batch operations. It claims 93% fewer API calls; that is its own claim.
• nrf24l01/ghidra-mcp: a fork of LaurieWired/GhidraMCP with a function hash index for carrying documentation across binaries.

The principle underneath: let deterministic software decompile, index, traverse, filter, and cache, and let the model form hypotheses, choose paths, and explain.

Which lever saved you the most? Visit rebelion.la to see what La Rebelion Labs is building.

Go Rebels!

This guide follows our full video course. You learn the theory, set up OpenSpec, and build a real minimum viable product, a donor dashboard for a non-profit, in three small, reviewed, tested changes. Everything is in the course repository: github.com/la-rebelion/mvp-with-sdd.

Why we work spec-first​

At La Rebelion Labs, we build MVPs during the pre-sale phase. We capture what the client needs, come back with something they can click, and iterate on their feedback. SDD is what makes that speed safe. Every feature starts as a short spec that the client, the AI agent, and the engineers can all read, so there are fewer misunderstandings and faster cycles.

The theory in five ideas​

1. The spec is the source of truth. You write a specification before you write code with AI, and it stays the reference for humans and agents alike. A spec is not a long prompt. A prompt disappears into chat history, while a spec is a reviewed, versioned file next to your code.

2. Specs used to drift. In the classic flow (requirements → design → code → test → deploy), requirements documents were written once and abandoned. Each handoff lost context, and the code and the document drifted apart.

3. Vibe coding breaks at scale. Prompting until it "feels right" is great for prototypes. For serious work, the decisions live only in chat, nobody reviews a plan, features break other features, and teammates can't onboard.

4. Aim for spec-anchored. Birgitta Böckeler's article on martinfowler.com describes three levels:

The article also warns against one-size-fits-all workflows, review overload, and a false sense of control. Our answer is small changes, short specs, and tests for every scenario.

5. Markdown, requirements, scenarios, deltas. A requirement states one observable behavior with SHALL or MUST. A scenario proves it with WHEN/THEN, and every good scenario becomes a test. Changes are written as delta specs (ADDED, MODIFIED, REMOVED) and merged into the living specs when you archive.

The workflow and the crew​

Set up​

You need Node.js 20.19 or newer, git, an editor, and an AI coding agent. OpenSpec supports more than 30 tools.

npm install -g @fission-ai/openspec@latest
cd mvp-with-sdd/starter
openspec init --tools claude,codex,github-copilot

openspec init creates openspec/specs/ (the source of truth), openspec/changes/ (one folder per change), and openspec/config.yaml, and it installs slash commands and skills for your agents. Restart your editor afterwards.

Remember the two places where you type commands: openspec … goes in the terminal, and /opsx:… goes in the agent's chat. The spelling varies by tool (/opsx-propose in Copilot, $openspec-propose in Codex), and init prints the right form.

Give the agent the constraints it can't guess in openspec/config.yaml: a pre-sale MVP, Node.js only, no frameworks or database, a test for every scenario, proposals that state what is out of scope, and tasks small enough to review in minutes.

The hands-on project​

The client, Rebel-I ONG, tracks donations in a hand-maintained spreadsheet. After the first call, we wrote a plan and a brief. We explore them with /opsx:explore and split the work into three changes, each with one intent.

Change 1: the donor dashboard​

/opsx:propose add-donor-dashboard creates the proposal, a delta spec, the design, and nine tasks. Review it before any code exists. The key scenario is "Donors are counted once": three donations from Ana make one active donor, not three. Then validate:

openspec validate add-donor-dashboard   # Change 'add-donor-dashboard' is valid
openspec list                           # add-donor-dashboard   0/9 tasks

Bonus tip: apply in chunks. Ask for tasks 1.1 to 2.1, then stop, review, and test. Then do 2.2 to 2.4, then the rest. You save tokens, review small diffs, and catch mistakes early.

Four tests (one per scenario) pass. GET /api/summary returns 6 active donors, 3 inactive donors, and $13,200 donated. openspec archive add-donor-dashboard --yes merges three requirements into openspec/specs/dashboard/spec.md and files the change in the archive.

Change 2: the import​

add-donation-import adds POST /api/import. An admin key is required (MUST): a missing or wrong key returns 401 and leaves the data unchanged. Each import replaces all data, and bad rows are skipped and counted. If no key is configured, imports are disabled, so the endpoint is secure by default. An HTTP integration test covers the 401. After this change, 9 tests pass.

Change 3: feedback becomes a MODIFIED requirement​

In the demo, the director asks who to call first, and to see the average gift. The delta for add-reactivation-list has an ADDED reactivation list and a MODIFIED Donor KPIs requirement, written out in full with the new average-gift scenario (100, 250.50, and 49.50 average to 133.33). When archived, it reports ~ 1 modified and + 1 added. 12 tests pass.

Release​

The checklist: npm test 12/12, openspec validate --all passing, ADMIN_KEY set in the environment and never committed, then commit, tag, and push.

Practice​

The repository's course/exercises.md covers each exercise from the video: set up the starter, add a "no donations" scenario, break a test on purpose, add the "wrong key" scenario, and build a fourth change, upcoming birthdays, as homework.

Next level​

Enable the expanded workflow (openspec config profile, then openspec update) to get /opsx:new, /opsx:continue, /opsx:ff, /opsx:verify, and /opsx:onboard. From there, add skills for your team's conventions, subagents that review and test against the specs, and MCP servers that let your agent check specs against real systems. For planning across repositories, see OpenSpec stores (beta).

Your turn​

Clone the course repository, run the loop on the starter, and build the fourth change. Subscribe for more courses, and visit rebelion.la to see what La Rebelion Labs is building.

Go Rebels!

ClickHouse is an open-source, column-oriented SQL database built for analytics. This guide explains what ClickHouse is, why it is fast, when it is the right choice, and when a transactional database fits better. You then install it, create a table designed around your questions, load one hundred million rows, and measure two real queries.

Understand What ClickHouse Is​

This section defines ClickHouse and the kind of work it is designed for.

ClickHouse is an open-source database management system, licensed under Apache 2.0, for Online Analytical Processing (OLAP). It speaks SQL and stores data column by column.

Most application databases handle Online Transaction Processing (OLTP): they read or write a few rows at a time, such as one order or one user. Analytical queries are different. They sweep across millions or billions of rows to count, sum, rank, and compare, and they often need to answer in less than a second. ClickHouse is designed for that second job.

Learn Why Columns Make Analytics Fast​

This section explains the storage choice behind ClickHouse's performance.

A row-oriented database stores each row together. That layout works well for fetching one complete record, but an analytical query that needs only two columns still reads every column of every row from disk.

ClickHouse stores each column separately, so a query reads only the columns it needs. Values of the same type sit next to each other, which helps compression and lets the processor work on them in batches. ClickHouse adds four more ideas on top of columnar storage:

• Parts and background merges. Each insert creates a small part on disk, and background merges combine parts later. Writes stay lightweight and do not block queries.
• Sorted data and skipping. Data is sorted by a key you choose, and ClickHouse skips blocks that cannot match a filter.
• Compression. Similar values stored together compress well, which saves disk space and speeds up scans.
• Vectorized, parallel execution. ClickHouse processes values in batches and spreads a single query across every CPU core.

Decide When ClickHouse Is the Right Choice​

This section maps common workloads to ClickHouse and to the alternatives.

The ClickHouse documentation highlights four main use cases:

• Real-time analytics: customer-facing dashboards and live leaderboards over a continuous stream of events.
• Observability: logs, metrics, and traces in one database, so you can correlate them without pre-aggregation.
• Data warehousing: ClickHouse paired with open table formats, such as Iceberg, on object storage.
• Agentic analytics: AI agents that need high concurrency and full-fidelity data, querying ClickHouse directly, including over the Model Context Protocol (MCP).

ClickHouse is not a replacement for every database. If your application needs transactional state, such as a worker claiming a job or several records changing together with constraints enforced, use a transactional database such as Postgres. ClickHouse also favors appending data over constant row-by-row updates. Many teams run both: Postgres for application state and ClickHouse for analytics, with the needed tables replicated across. Row count alone does not decide the choice; your queries and correctness requirements do.

Prerequisites​

Before you begin, you need:

• A Linux, macOS, or FreeBSD machine. On Windows, use the Windows Subsystem for Linux (WSL).
• A terminal with curl.
• About 250 MB of free disk space for the binary, plus roughly 1 GB for the example data.

Install ClickHouse​

This section installs the single ClickHouse binary and starts a server.

1. Download the binary for your system:

   $ curl https://clickhouse.com/ | sh
   

   The script selects the right build and saves a single file named clickhouse in the current directory.

2. Start the server so your data persists between restarts:

   $ ./clickhouse server
   

   The server stores its data in the current directory.

3. Open a second terminal in the same directory and check the connection:

   $ ./clickhouse client --query "SELECT version()"
   

   The command prints the server version, for example 26.10.1.2511.

The same binary also runs clickhouse-local, a SQL engine for files that needs no server. The Query a File Without a Server section uses it.

Create a Table Designed Around Your Questions​

This section creates the running example: page views for a web store.

1. Save the following table definition as example.sql:

   CREATE TABLE page_views
   (
       ts          DateTime,
       user_id     UInt32,
       page        LowCardinality(String),
       country     LowCardinality(String),
       duration_ms UInt32
   )
   ENGINE = MergeTree
   ORDER BY (page, ts);
   

   MergeTree is the main ClickHouse table engine and manages parts and merges. ORDER BY (page, ts) sorts the data on disk by page, then by time; choose this order based on the filters you use most. LowCardinality stores columns with few distinct values, such as page names, as compact codes.

Load One Hundred Million Rows​

This section generates realistic test data with a single insert statement.

1. Append this insert to example.sql. It uses the numbers table function to create one hundred million page views spread across the last thirty days:

   INSERT INTO page_views
   SELECT
       now() - toIntervalSecond(rand(1) % (30 * 86400)) AS ts,
       rand(2) % 1000000 AS user_id,
       ['/home', '/home', '/home', '/home', '/docs', '/docs', '/docs', '/pricing', '/pricing', '/blog', '/signup', '/checkout'][rand(3) % 12 + 1] AS page,
       ['US', 'US', 'US', 'MX', 'MX', 'BR', 'ES', 'DE', 'IN', 'IN'][rand(4) % 10 + 1] AS country,
       rand(5) % 60000 AS duration_ms
   FROM numbers(100000000);
   

   Each rand(n) call uses a different argument, so the columns receive independent random values.

2. Run the file:

   $ ./clickhouse client --multiquery < example.sql
   

   On a 16-core laptop, the insert finishes in about 20 seconds.

3. Confirm the row count:

   $ ./clickhouse client --query "SELECT count() FROM page_views"
   

   The output is 100000000.

Ask the Dashboard Question​

This section runs the top-pages query and measures how much data it reads.

Before you run it, guess how many of the one hundred million rows a seven-day filter needs to read.

1. Run the query with timing and profile events enabled:

   $ ./clickhouse client --time --print-profile-events --profile-events-delay-ms=-1 --query "SELECT page, count() AS views, uniq(user_id) AS visitors, round(avg(duration_ms) / 1000, 1) AS avg_seconds FROM page_views WHERE ts >= now() - INTERVAL 7 DAY GROUP BY page ORDER BY views DESC"
   

   The run in this guide returned the following, in 0.30 to 0.41 seconds:

   /home       7778468   1001503   30
   /docs       5833597    998999   30
   /pricing    3889269    980906   30
   /checkout   1947108    858186   30
   /blog       1944268    859280   30
   /signup     1943348    857508   30
   

   The profile events report SelectedRows: 24355072. ClickHouse read about 24.4 million rows instead of 100 million, because the data inside each page is sorted by time. uniq returns an approximate distinct count, which is fast and accurate enough for dashboards.

Make the Sort Key Work for You​

This section shows how a query that matches the sort key reads even less data.

1. Count checkouts by country:

   $ ./clickhouse client --time --print-profile-events --profile-events-delay-ms=-1 --query "SELECT country, count() AS checkouts FROM page_views WHERE page = '/checkout' GROUP BY country ORDER BY checkouts DESC"
   

   The query returned US 2,500,870, IN 1,669,050, MX 1,665,220, BR 835,527, ES 834,682, and DE 832,776 in 0.036 seconds, with SelectedRows: 8527872. Because the table is sorted by page first, every checkout row sits in one contiguous range.

2. Inspect compression per column:

   $ ./clickhouse client --query "SELECT name, formatReadableSize(data_compressed_bytes) AS on_disk, formatReadableSize(data_uncompressed_bytes) AS raw FROM system.columns WHERE table = 'page_views'"
   

   The sorted page column stores 95.55 MiB of raw values in about 160 KiB. Random columns such as user_id compress far less; production data usually contains more patterns to exploit.

See the Skipping in the Query Plan​

This section confirms, with the query plan, how the primary key avoids reading data.

ClickHouse divides each part into granules, blocks of 8,192 rows by default, and keeps a small sparse index with one entry per granule. A filter on the leading sort key column can use that index to find matching granules with a binary search instead of scanning the column.

1. Ask ClickHouse to explain the checkout query with index details:

   $ ./clickhouse client --query "EXPLAIN indexes = 1 SELECT country, count() FROM page_views WHERE page = '/checkout' GROUP BY country"
   

   The relevant part of the output reads:

   PrimaryKey
     Keys:
       page
     Condition: (page in ['/checkout', '/checkout'])
     Parts: 5/5
     Granules: 1022/12210
     Search Algorithm: binary search
   

   The plan selects 1,022 of 12,210 granules, about 8 % of the table. The part count depends on how far background merges have progressed, so your number of parts can differ.

2. Compare this with the seven-day query from the previous section. Time is the second sort key column, so ClickHouse can narrow the range only inside each page, which explains why it read about a quarter of the rows. If most of your dashboards filter by time first, a sort key such as ORDER BY (ts, page) or a projection with a different order can serve them better. Test with your own queries before you decide.

Use EXPLAIN indexes = 1 whenever a query is slower than you expect. It shows whether the primary key participates and how many granules survive each index.

Query a File Without a Server​

This section analyzes a CSV file directly with clickhouse-local.

1. Create a small orders.csv file:

   $ printf 'order_id,country,amount\n1,MX,120.50\n2,US,89.99\n3,MX,42.00\n4,ES,15.25\n5,US,240.00\n' > orders.csv
   

2. Group and sum it with SQL:

   $ ./clickhouse local --query "SELECT country, count() AS orders, sum(amount) AS revenue FROM file('orders.csv') GROUP BY country ORDER BY revenue DESC"
   

   The output lists US with 2 orders and 329.99 in revenue, MX with 2 and 162.5, and ES with 1 and 15.25. Tables you create in clickhouse-local are temporary, so use the server when you want to keep data.

Choose a Deployment Mode​

This section maps the ways to run ClickHouse to the situations they suit.

Troubleshoot Common Problems​

This section maps first-hour symptoms to their fixes.

Conclusion​

You now know that ClickHouse is an open-source columnar database for analytics, why columnar storage, sorting, compression, and vectorized execution make it fast, and when a transactional database such as Postgres fits better. You installed ClickHouse, loaded one hundred million rows in about twenty seconds, answered a dashboard question in about a third of a second, and saw a query that matches the sort key read 8.5 million rows instead of 100 million.

As a next step, pick one question your team asks every week and design a table around it, starting with the ORDER BY clause. For more guides like this one, visit La Rebelion Labs.

REA, short for Reverse Engineer Anything, closes that gap. It gives your AI coding agent real reverse-engineering tools and returns every finding with the evidence behind it. At the end of this guide, you have REA connected to your agent, you have traced a real feature from a button to the code that writes a file, and you have verified one of the claims yourself.

Understand What REA Does​

This section explains what REA is and why its results are different from a model's guess.

REA is an open-source Model Context Protocol (MCP) server and Command Line Interface (CLI), published on npm as rea-agents. Your agent stays the assistant you talk to; REA is the set of instruments it reaches for. It inspects native binaries, JavaScript and Electron apps, .NET assemblies, Android packages, websites, saved network captures, and more.

The difference lies in what comes back. Every REA result carries its evidence:

• the exact artifact it read, identified by its digest;
• the location of each finding, down to the file and line;
• a clear split between what REA observed, what it inferred, and what remains unknown.

That split matters. When your agent explains a feature, you can trace every claim back to bytes on disk instead of trusting a plausible-sounding answer.

Decide When REA Is the Right Tool​

This section helps you recognize the situations where REA pays off and the ones it does not support.

Reach for REA when you need to understand behavior and the source is not available. Three situations come up again and again:

• Learn from a feature. You see a feature in an app and want something similar in your own product. REA explains how it works so your agent can write and test your own version.
• Debug or audit software you own or are authorized to examine. Examples include a legacy binary, a vendor library, or a desktop build with no symbols.
• Compare versions. You need to know what changed between two shipped versions of an application.

REA is the wrong tool for circumventing DRM, license checks, or anti-cheat systems, and for copying proprietary code. The project does not support those uses. Possessing a file does not grant permission to do everything with it, so keep your work lawful and authorized.

Prerequisites​

Before you begin, you need:

• Node.js 22.19 or newer on the 22 line, 24.11 or newer on the 24 line, or version 26 and up, with npm.
• An AI agent that supports local MCP servers, such as Claude Code, Codex, Cursor, or Gemini CLI.
• For deep analysis of compiled programs only: Ghidra, Hopper, or IDA. JavaScript, Electron, and .NET inspection need no analysis engine.
• On Linux: the standard ps command from your distribution's procps or procps-ng package. REA uses it to check process ownership before launching analysis tools.

Check your Node.js version:

$ node -v

If the output shows an older version, upgrade Node.js before you continue.

Connect REA to Your Agent​

This section registers REA with your agent in one guided command.

1. Run setup with the latest package:

   $ npx rea-agents@latest setup
   

   Setup lists the supported agents. Select the ones you use.

2. Review the plan. Setup shows every configuration file it intends to change and where it installs the workflow instructions for your agent. Nothing changes until you approve. Setup backs up your existing configuration and preserves unrelated entries, and pressing Ctrl-C makes no changes.

3. Restart every agent named in the completion message. Agents load MCP registrations at startup, so skipping the restart is the most common reason REA's tools do not appear.

Ask Your Agent About a Real Feature​

This section runs your first investigation against a small Electron notes app.

REA's website provides a six-file Electron example with a single Export notes button. Clicking it creates a CSV file somewhere on your computer. Before you read further, guess where that file goes and which columns it contains.

1. Download the example from rea.tools/examples/notes-example.zip and unpack it.

2. Ask your agent a specific question about the folder:

   Use REA to find what happens when the Export notes button is clicked. Show where notes.csv is written, which fields it contains, and the relevant files and lines.
   

   The prompt names the feature, asks for a concrete outcome, and demands files and lines. That last requirement keeps the answer grounded in evidence.

Your agent hands the folder to REA's JavaScript application analysis. REA parses the code as inert text. It never installs or launches Electron, and it never runs the app.

Follow the Evidence Trail​

This section walks through the path REA recovers from the button to the file writer.

The answer arrives as a path through three files:

• renderer.js: the button's click handler calls window.notes.exportCsv().
• preload.js: a context bridge exposes the notes object, and exportCsv sends an Inter-Process Communication (IPC) message on the channel notes:export.
• main.js, lines 8–12: the main process handles that exact channel, builds a path in the user's Downloads folder, formats the notes with toCsv, and writes notes.csv.

ipcMain.handle("notes:export", () => {
  const destination = path.join(app.getPath("downloads"), "notes.csv");
  writeFileSync(destination, toCsv(notes), "utf8");
  return destination;
});

The file lands in Downloads, and its columns are id and title. REA paired the renderer's message with the main-process handler by reading the code. Your agent did not invent that link; it pointed at it.

Check a Prediction Yourself​

This section turns one claim into an experiment you run in seconds.

A comma separates CSV columns, so a note title that contains a comma and quotation marks is a good test of the formatter.

1. Ask your agent to predict the CSV output for a note with ID 1 and the title Hello, "REA".

2. Open a terminal in the unpacked example folder and run the app's own formatter:

   $ node -e 'const { toCsv } = require("./csv.js"); process.stdout.write(toCsv([{ id: 1, title: "Hello, \"REA\"" }]))'
   

   The output shows the title in one quoted field, with each quotation mark doubled:

   id,title
   1,"Hello, ""REA"""
   

Prediction followed by verification is the habit that turns reverse engineering from guesswork into engineering.

Run the Same Analysis from Your Terminal​

This section reproduces the investigation with the CLI, which suits scripts and Continuous Integration (CI) pipelines.

The CLI uses the same workflows and the same evidence format as the MCP server.

1. Install the rea command globally and list its commands:

   $ npm install --global rea-agents
   $ rea --help
   

   The help output lists every workflow, from Android packages to WebAssembly.

2. Analyze the example folder and save the evidence to a file:

   $ rea analyze-javascript-application /absolute/path/to/notes-electron --json > notes-evidence.json
   

   Evidence for a real application can reach hundreds of megabytes, so save it instead of printing it.

3. Project a summary view from the saved evidence:

   $ jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' notes-evidence.json > notes-view.json
   $ rea inspect-analysis-view notes-view.json
   

   For the notes app, the summary reports six relevant files, four parsed JavaScript files, one context bridge, one main-process handler, and one renderer message paired to that handler, with complete application coverage.

For a large application, the summary view turns evidence of hundreds of megabytes into roughly ten kilobytes, small enough for your agent to read in one pass.

Trace One Feature Through the Graph​

This section follows a single feature through every connection REA recovered.

A summary tells you what exists; a feature trace tells you how it connects.

1. Build a trace input from the saved evidence and a literal seed, here the channel name notes:export:

   $ node --input-type=module -e 'import { readFileSync, writeFileSync } from "node:fs"; const application = JSON.parse(readFileSync("notes-evidence.json", "utf8")); writeFileSync("trace-input.json", JSON.stringify({ application, seed: { kind: "string", value: "notes:export" }, direction: "both" }));'
   

2. Run the trace:

   $ rea trace-application-feature ./trace-input.json --json
   

   On the notes app, the trace matches five seeds and returns 32 nodes connected by 45 edges, including the IPC handler, the context bridge, and the file system module. It reports 31 observed facts and 48 inferred facts separately.

REA never blends what it saw with what it concluded. That separation lets you trust the answer on an application far larger than this example.

Go Deeper into Native Binaries​

This section extends the same approach to compiled machine code.

Configure Ghidra, Hopper, or IDA, and REA drives the engine for you. Commands such as rea search, rea function, rea decompile, and rea trace return pseudocode, assembly, strings, symbols, calls, and references.

1. List the available engines:

   $ rea providers --json
   

2. Trace a literal through a native program, selecting the engine explicitly when more than one supports the target:

   $ rea trace /absolute/path/to/program "search" --provider ghidra --json
   

One of the project's published case studies shows the full arc. It starts from the classic Windows game DX-Ball, follows a sound call into the helper that converts a brick's screen position into stereo pan, reads the original instructions, and rebuilds the calculation in C. The reconstruction passes 3,205 test cases against the original x86 code and reproduces all 63 bytes of the compiled function.

Match the Target to the Workflow​

This section maps common targets to the workflow and tooling each one needs.

Static inspection reads files without running them. Runtime capture, such as driving a browser scenario or recording a process, runs the target with your user permissions. Treat those workflows with the same care you give any untrusted program, and use an isolated environment when the target is unfamiliar.

Troubleshoot Common Problems​

This section maps the most frequent symptoms to their fixes.

Conclusion​

You connected REA to your agent with one command, asked a precise question about a real app, and received a path from a button to a file writer with line numbers. You tested a prediction against the app's own formatter, reproduced the analysis from the terminal, projected a compact summary, and traced a feature through its graph.

Take the next step with an app you are authorized to examine. Pick one button or one behavior, ask your agent how it works, demand the files and the lines, and check one claim yourself. Start with npx rea-agents@latest setup, and find guides and case studies on the REA website and in the REA repository.

Every new frontier AI model creates the same conversation.

"Should I pay for it?"

I think that's the wrong question.

The better question is:

"What can I build with it today that will continue creating value long after I stop using it?"

That shift in mindset is the difference between using AI as a tool and harnessing AI as infrastructure.

A recent post on X proposed an interesting experiment: before Claude Fable 5 moves to usage-based pricing, use it to extract its reasoning style into a reusable operating manual. Then use that manual to guide a less expensive model such as Opus 4.8 (or any other capable model) for day-to-day work. The underlying idea is simple: own the workflow instead of depending entirely on the premium model.

Whether this specific technique delivers the expected results remains to be validated. But the bigger lesson is much more important.

It introduces a concept I've been thinking about for quite some time:

Harnessing AI instead of merely consuming AI.

The model isn't the asset​

Models will improve.

Models will become cheaper.

Models will change pricing.

Models will disappear.

We've already watched this happen repeatedly.

A model that seems revolutionary today may become a commodity six months from now. Anthropic's move toward usage-based pricing for Claude Fable 5 is simply another reminder that access models change over time.

If your competitive advantage depends entirely on having access to one specific model...

...your advantage isn't really yours.

But if you use that model to create something reusable...

...that asset remains yours.

Think like an engineer​

Software engineers learned this lesson decades ago.

Nobody rewrites authentication for every application.

Nobody writes a database engine every weekend.

Nobody rebuilds Kubernetes before deploying an application.

We build reusable components.

Frameworks.

Libraries.

Patterns.

Infrastructure.

Those components become leverage.

AI should be no different.

What is an AI harness?​

I've written before that AI Harnesses exist to reduce friction, amplify capability, and deliver outcomes.

This idea fits perfectly here.

A harness isn't the model.

A harness is everything surrounding the model that makes it consistently useful.

That includes:

• Prompt libraries
• Operating manuals
• Decision frameworks
• Evaluation rubrics
• Checklists
• Workflow templates
• Knowledge bases
• Verification procedures
• Memory structures
• Context engineering
• Automation workflows

These are reusable assets.

The model simply powers them.

Rent intelligence. Own systems.​

Imagine hiring the world's best consultant.

Would you ask them to answer your emails every day?

Probably not.

You would ask them to help design:

• your operating procedures
• your sales playbook
• your hiring framework
• your onboarding process
• your pricing strategy

Once those exist, your team can execute them repeatedly.

The consultant becomes an accelerator.

Not a permanent dependency.

Frontier AI models should be treated exactly the same way.

The 80/20 strategy​

This is in fact the strategy that I am using with Clawne Me and My Clawster in my own AI workflows. Cost efficiency is key: I reserve the premium models for tasks that create leverage and use more economical models for routine execution.

Suppose a premium model costs significantly more than your daily model.

Instead of running every task through the expensive model:

Use it for the work that creates leverage.

Examples:

• designing prompt architectures
• creating evaluation frameworks
• documenting reasoning processes
• generating reusable workflows
• defining quality standards
• building knowledge maps
• creating playbooks

Then use more economical models for:

• summarization
• customer responses
• documentation updates
• report generation
• email drafting
• content adaptation
• routine coding
• repetitive analysis

The expensive model becomes your architect.

The affordable model becomes your operator.

This requires discipline​

Here's the difficult part.

Most people won't do it.

Not because it's technically hard.

Because it requires changing how they think.

It's much easier to open ChatGPT or Claude every morning and ask:

"Help me with today's work."

Instead, you need to ask:

"How can I make sure I never have to solve this problem again?"

Those are completely different questions.

One produces output.

The other produces assets.

Planning before prompting​

This is where planning becomes critical.

Before opening any AI model, classify the task.

Ask yourself:

Is this execution?​

Or...

Is this infrastructure?​

Execution tasks disappear after they're completed.

Infrastructure tasks continue producing value.

For example:

Execution

• Write today's email
• Summarize today's meeting
• Review one document

Done.

Finished.

Value expires quickly.

Infrastructure

• Create an email framework
• Design a meeting summary template
• Build a document review methodology

These continue paying dividends every time you reuse them.

Your library becomes your competitive advantage​

Imagine doing this consistently for a year.

Instead of thousands of isolated conversations...

You build:

• 40 reusable workflows
• 60 prompt templates
• 20 evaluation frameworks
• 15 decision trees
• 10 operating manuals
• dozens of specialized checklists

Suddenly your AI system becomes smarter.

Not because the model improved.

Because your harness improved.

That's leverage.

Don't blindly trust the experiment​

Now, an important disclaimer.

The X post suggests extracting Fable's reasoning style into an operating manual and reproducing it with another model.

Will it work perfectly?

Probably not.

Reasoning quality depends on more than prompts alone. It also depends on model architecture, training, inference capabilities, and other characteristics that cannot simply be copied.

However...

That's not the point.

The experiment itself is valuable.

If it improves your results by 20%, 30%, or even 50%, you've learned something useful.

Run the experiment.

Measure it.

Compare outputs.

Iterate.

Treat AI like engineering.

Not magic.

Harnesses compound over time​

One of the biggest misconceptions about AI is believing productivity comes from better prompts.

I don't think that's true.

Productivity comes from better systems.

Every reusable asset you create becomes another component inside your AI harness.

Eventually your process looks something like this:

Problem
      ↓
Planning
      ↓
Select Framework
      ↓
Load Knowledge
      ↓
Apply Workflow
      ↓
Execute with AI
      ↓
Verify Results
      ↓
Improve Framework

Notice something?

The model is only one step.

Everything else belongs to you.

How to build your own AI harness​

If you want to apply this idea, start with a simple weekly routine.

Monday: Identify recurring work​

Look for tasks you repeat every week.

Tuesday: Build a reusable asset​

Use your strongest AI model to create:

• a workflow
• a checklist
• a prompt library
• a decision guide
• an evaluation rubric

Wednesday–Friday: Execute​

Run daily work using that reusable asset, even with a more affordable model if it performs well enough.

Friday: Review​

Ask:

• What worked?
• What failed?
• What should become part of the permanent workflow?

Each week, your harness becomes stronger.

Final thoughts​

Reflect on how your organization can leverage AI effectively using this framework:

• Strengths: What internal capabilities and resources give you an advantage in building AI harnesses?
• Weaknesses: Where are the gaps in your current processes, skills, or infrastructure?
• Opportunities: What emerging AI technologies or trends can you capitalize on?
• Threats: What external factors could hinder your AI adoption or reduce its effectiveness?

The landscape of AI will continue evolving. Models will improve. Pricing will change. New leaders will emerge, and others will disappear.

These are external forces beyond our control.

What we can control is the systems we build around them.

The organizations that gain the most from AI won't necessarily be those with access to the smartest model, they'll be the ones that consistently convert intelligence into reusable assets.

That's what harnessing AI really means.

Not replacing people. Not chasing every new model.

But building a disciplined system where planning creates reusable assets, those assets guide execution, and every completed task strengthens the next one.

That's leverage.

And unlike any single model, leverage compounds.

Key takeaways​

• Separate creation from execution. Use premium AI models to design reusable frameworks, and use more cost-effective models for routine work.
• Treat AI outputs as assets. Turn successful prompts, workflows, and decision processes into documented playbooks instead of one-off conversations.
• Build your AI harness intentionally. Your prompts, memory, checklists, evaluation rubrics, and workflows are the infrastructure that creates long-term value.
• Experiment instead of assuming. Test ideas like reasoning-style extraction, measure the results, and refine your process based on evidence rather than hype.
• Invest in leverage. Every reusable asset reduces future effort, improves consistency, and increases the return on every AI interaction that follows.
• Iterate continuously. Regularly review and refine your workflows, prompts, and evaluation criteria to ensure your AI harness evolves with your needs and the capabilities of AI models.
• Focus on compounding value. Each improvement to your AI harness should make future work easier and more effective, creating a cycle of increasing returns over time.
• Document your learnings. Keep a record of what works and what doesn't, so that your team can benefit from past experiences and avoid repeating mistakes.
• Share knowledge across your team. Ensure that insights, successful strategies, and lessons learned are communicated effectively so that everyone can benefit from the collective experience.

What matters most is not having the smartest AI model, but having a system that consistently turns intelligence into reusable assets and compounds value over time.

Go Rebels! ✊🏽

That is great news, but it also changes where value lives.

The core advantage is no longer just model access. It is your ability to design, govern, and operate AI systems that produce reliable business outcomes.

TL;DR​

• Frontier models are converging in capability for most business tasks.
• The new moat is orchestration: memory, tools, verification, guardrails, and workflow design.
• Teams that treat AI like production software, not magic autocomplete, will win.
• Start simple, instrument everything, and only add complexity when metrics justify it.

Why Models Are Becoming Commodities​

For the last two years, the market has focused on model comparisons:

• GPT vs Claude vs Gemini
• Benchmark scores
• Context windows
• Token pricing

Those factors still matter, but they are increasingly table stakes.

Most companies can now access strong general-purpose models through APIs, cloud platforms, open-source weights, or managed hosting. As access normalizes, competitive advantage shifts up the stack.

The pattern mirrors cloud computing:

• Early cloud era: "Provider choice is the strategy."
• Mature cloud era: "Architecture and operations are the strategy."

AI is following the same curve.

The New Moat: Orchestration Over Raw Model Access​

When model quality differences narrow, the winners are not the teams with a slightly better prompt. They are the teams with better systems.

In practice, the differentiator becomes:

• Workflow design
• Persistent memory
• Tool integration
• Verification and evaluation
• Safety and policy enforcement
• Business-specific context

In other words: the model is a component. The system is the product.

1) Agent Orchestration Beats One Giant Agent​

Most AI failures happen because a single agent is overloaded with planning, research, execution, and quality control.

Instead of one all-purpose agent, use role-separated pipelines:

Planner
  -> Researcher
  -> Executor
  -> Verifier

This structure improves reliability because each stage has a clear objective, interface, and success criteria.

Practical takeaway:

1. Split one complex prompt into at least two stages this week: execution and verification.
2. Add explicit pass/fail criteria to the verifier stage.
3. Track failure modes by stage so you know where to improve.

2) Memory Is a First-Class Infrastructure Layer​

Stateless prompting works for demos. It breaks for real operations.

Production-grade AI systems need at least four memory types:

User Memory​

Who this user is, preferences, constraints, and history.

Task Memory​

What has already happened in the current workflow.

Organizational Memory​

Policies, playbooks, decisions, and internal knowledge.

Procedural Memory​

How work is usually done, including standard operating sequences.

Practical takeaway:

1. Define one source of truth per memory type.
2. Set freshness rules for each source.
3. Add retrieval tests: can your system fetch the right policy or prior decision on demand?

3) Verification Is the Difference Between Demo and Production​

The industry asked: "Can the model generate output?"

The production question is: "How do we know the output is correct enough to act on?"

Use a default loop:

Generate
-> Verify
-> Correct
-> Verify again

Verification can include:

• Policy checks
• Schema validation
• Tool-result cross-checks
• Unit-style assertions for deterministic steps
• Human review for high-risk actions

Practical takeaway:

1. Add one verifier before any external side effect.
2. Block writes, purchases, and deletes unless verification passes.
3. Log failed checks to build a safety and quality backlog.

4) Safety Boundaries Are System Design, Not Prompt Design​

Most enterprise AI safety controls live outside the model.

Core controls include:

• Tool allowlists: what APIs can be called
• Action controls: what operations are allowed
• Approval gates: when human sign-off is required
• Budget limits: token and spend caps
• Audit logs: who did what, when, and why

Practical takeaway:

1. Define risk tiers for actions.
2. Require approval for tier-2 and tier-3 actions.
3. Enforce hard budget and tool boundaries at the orchestrator layer.

5) Simplicity Is a Strategic Advantage​

A common anti-pattern in AI architecture is unnecessary complexity.

Teams keep adding agents, routers, memories, and evaluators before proving they are needed.

Sometimes the best design is:

One prompt
One tool call
One validated output

Practical takeaway:

1. Start with the smallest architecture that can pass your quality bar.
2. Add components only when a measurable failure mode requires them.
3. Review architecture monthly and remove non-contributing layers.

A Practical 30-60-90 Day Implementation Plan​

If you are building an AI platform, use this rollout sequence.

Days 1-30: Stabilize Basics​

• Pick one high-value workflow.
• Implement clear stage separation (execute + verify).
• Add logging, latency, quality, and cost metrics.
• Define tool and action boundaries.

Days 31-60: Add Durable Context​

• Implement user, task, and organizational memory.
• Add retrieval quality checks.
• Introduce policy validation and automated correction loops.
• Add human approvals for high-impact actions.

Days 61-90: Optimize and Scale​

• Compare model providers by workflow-level outcomes, not only benchmarks.
• Prune unnecessary orchestration components.
• Expand to additional workflows using reusable templates.
• Publish an internal AI operations standard.

Where La Rebelion Fits in This Stack​

This is the direction behind the (https://rebelion.la/labs) ecosystem:

• HAPI MCP: tool layer
• OrcA: workflow and Arazzo orchestration
• My Clawster: orchestration control plane
• Clawne Me: memory, context, and user layer

The strategic value is not "we use model X."

The strategic value is "we can coordinate models, tools, workflows, and memory into a reliable AI operating system."

Final Takeaway​

Over the next 3-5 years, model intelligence will keep improving and becoming easier to access.

The durable winners will be organizations that build the best AI operating systems around those models: orchestration, memory, verification, guardrails, and disciplined simplicity.

The model is important.

The system is decisive.

What's your strategy to win in the era of AI commoditization?

Go Rebels! ✊🏼

FAQ​

Are AI models becoming commodities?​

Yes, for many business use cases. Capability differences still exist, but access to strong models is broad enough that architecture and operations increasingly drive outcomes.

What is agent orchestration in AI?​

Agent orchestration is the design and control of multi-step AI workflows, including task routing, tool usage, memory retrieval, verification, and safety enforcement.

What matters more than model choice in enterprise AI?​

In many cases: memory quality, verification coverage, policy controls, workflow design, and cost governance matter more than marginal model benchmark differences.

Why do AI systems fail in production?​

Common causes are missing context, weak verification, unclear tool boundaries, absent approval gates, and over-complex orchestration with poor observability.

How do you build a reliable AI system?​

Start with one workflow, separate execution from verification, add durable memory, enforce safety boundaries at the orchestration layer, and scale only after metrics confirm reliability.

After a painful production incident this week, my answer is:

Yes, ORMs still matter. But blind trust in abstractions does not.

The Incident (Anonymized)​

A customer flow in production kept returning a business-rule conflict. The strange part:

• The customer looked eligible in an internal troubleshooting tool.
• The same customer looked ineligible in the portal transaction flow.
• Verification data was valid.
• Branch resolution looked valid.

Everything looked correct, yet the live flow still failed.

We chased auth freshness, payload format, environment flags, and campaign config. Useful, but not the root cause.

The real issue was subtler:

• The troubleshooting tool used a direct SQL path.
• The transaction flow used ORM-composed queries.
• Those two paths were logically intended to be equivalent.
• In practice, they were not equivalent under real production data.

This was not "SQL bad, ORM good" or "ORM bad, SQL good."

It was equivalence drift between two query construction styles.

Was Drizzle "Hiding" the Bug?​

Short answer: partly yes, in the same way any abstraction can hide behavior.

Longer answer:

• We assumed the ORM-generated query semantics matched the SQL semantics we had in mind.
• We did not validate that assumption early enough against production-like conditions.
• The troubleshooting endpoint, built with explicit SQL, became the "truth probe" that exposed the mismatch.

So it wasn’t that the ORM was broken by definition. It was that abstraction reduced visibility right when we needed semantic certainty.

That can happen with any ORM, not just Drizzle.

Why This Matters More in the AI Era​

AI accelerates implementation dramatically, but it also amplifies an old engineering risk:

fast confidence in unverified assumptions.

When AI writes ORM-based code quickly, we often get:

• Clean types
• Passing local tests
• Readable service methods
• Seemingly correct business logic

But we still need to ask:

1. Does this query shape produce the same rows as the intended SQL?
2. Does it stay equivalent when data cardinality and relationships change?
3. Are we debugging behavior, or abstractions of behavior?

AI makes code generation cheap. It does not make semantic verification optional.

Are ORMs Still Useful?​

Absolutely. ORMs still provide massive value:

• Productivity: less repetitive CRUD and mapping boilerplate.
• Safety by default: parameterized queries and fewer injection footguns.
• Schema ergonomics: typed models and centralized constraints.
• Relationship handling: cleaner expression of common joins and associations.
• Team readability: business logic can be easier to follow in service code than in raw SQL blocks.

These benefits did not disappear because AI got better.

Where ORMs Hurt (and AI Can Make It Worse)​

In critical flows, the pain points become obvious fast:

• Implicit query semantics are harder to reason about during incidents.
• Composition patterns can diverge from your mental SQL model.
• Debugging becomes "inspect builder state" instead of "read exact query intent."
• AI-generated abstractions can look right while still being semantically off.

So the core tradeoff remains:

• ORMs optimize developer throughput.
• Direct SQL optimizes semantic explicitness.

The trick is not choosing one forever. The trick is choosing the right abstraction level per path.

A Practical Pattern That Worked for Us​

What saved us was not a heroic guess. It was architecture and observability:

• We had a troubleshooting path using explicit SQL.
• It provided deterministic visibility into eligibility decisions.
• We compared ORM-driven and SQL-driven outcomes on the same input.
• We aligned the production query shape to the proven SQL semantics.

In other words, we used a dual-lens strategy:

• ORM for day-to-day velocity.
• Explicit SQL for observability and critical decision points.

That combination reduced ambiguity fast.

A Better Rule for 2026​

Instead of "ORM vs SQL," use this operating rule:

Use ORMs by default. Require SQL-level validation for high-impact business decisions.

Examples of high-impact paths:

• Eligibility and pricing decisions.
• Financial calculations.
• Permission and access checks.
• Deduplication and idempotency logic.
• Anything that can produce customer-facing conflicts at scale.

Checklist: Keep ORMs, Avoid Blind Spots​

1. Log decision inputs and outputs (not just errors).
2. Mirror one critical query path in explicit SQL for diagnostics.
3. Test semantic equivalence between ORM and SQL for edge cases.
4. Treat generated query shape as part of behavior, not an implementation detail.
5. Use AI to draft queries, then verify with production-like data before trusting conclusions.

Final Take​

AI copilots did not make ORMs obsolete.

They made one thing more important: verification discipline.

ORMs are still excellent tools for human teams. But with AI accelerating output, we should stop treating ORM-generated behavior as automatically correct in critical paths.

Keep the abstraction. Add a truth probe.

That one shift can save days of production back-and-forth.

But one risk grows with it:

You can ship a lot of correct-looking logic that is semantically wrong under edge conditions.

A practical fix is to add a truth-probe endpoint.

A truth probe is a diagnostics-only API route that evaluates business decisions with explicit, inspectable logic and returns step-by-step evidence.

This post shows how to design one safely.

Why Truth Probes Exist​

In production incidents, teams often need answers to questions like:

• Which rules were evaluated?
• Which filters removed the candidate set?
• Which data source won in identity, branch, or scope resolution?
• Did this fail because of eligibility, status, or configuration?

Typical application services return final outcomes only. That is not enough during root-cause analysis.

Truth probes expose the decision path, not only the decision result.

Core Design Principle​

A truth probe should be:

• deterministic
• read-only
• explicit
• low-risk
• removable from normal user flows

Think of it as an X-ray for business logic.

Architecture Pattern​

Use two paths:

• Primary path: regular application service using your standard stack and abstractions.
• Probe path: diagnostics endpoint that executes explicit decision steps and returns per-step results.

These paths should consume the same inputs and target the same business decision.

If results diverge, you have a semantic drift signal.

Recommended Endpoint Contract​

Input:

• actor or customer identifier
• context identifiers (branch, market, channel)
• transaction-like inputs (amount, document reference, date)
• mode (all steps or single step)

Output:

• execution environment
• ordered list of step results
• each step includes: id, title, query or check summary, status, row count, and lightweight evidence

Include reason codes for final classification.

Avoid opaque booleans.

Step Model Example​

A useful sequence for eligibility-like decisions:

1. Subject state check
2. Membership and segmentation check
3. Context resolution check
4. Candidate selection check
5. Scope mapping check
6. Targeting key snapshot
7. Eligibility matrix with reason code

This pattern keeps debugging linear and explainable.

Security and Safety Requirements​

Truth probes are powerful and must be constrained.

Minimum controls:

• admin-only authorization
• explicit role and permission checks
• strict rate limits
• read-only data access
• no mutation side effects
• bounded response sizes
• environment-aware visibility

Never expose raw secrets, personal data, or full payload dumps.

Prefer redacted snapshots and stable identifiers.

SQL vs ORM Inside the Probe​

For high-impact diagnostics, explicit SQL is often the better choice.

Why:

• easy to reason about exact semantics
• straightforward to compare with expected query shape
• easier incident communication across team roles

This does not mean abandoning ORMs in the product path. It means using explicit logic where observability and semantic certainty matter most.

How to Keep Probe and Product Aligned​

Truth probes fail if they drift from product behavior.

Use these guardrails:

1. Share input normalization utilities between paths.
2. Reuse reason-code enums and classification constants.
3. Add equivalence tests that compare product and probe outcomes on known scenarios.
4. Add incident replay tests from anonymized production cases.
5. Version your probe steps when business rules evolve.

Anti-Patterns to Avoid​

• Probe endpoint that mutates state.
• Probe response that only says pass or fail.
• Probe logic copied once and never updated.
• Probe hidden behind unstable feature flags in incidents.
• Probe that returns too much data to be actionable.

Implementation Checklist​

• Define a stable decision reason taxonomy.
• Build a read-only diagnostics route under admin scope.
• Implement ordered step execution with isolated error handling.
• Return structured outputs per step.
• Add strict auth, rate limiting, and redaction.
• Add product vs probe equivalence tests.
• Document when to use probe mode all vs step.

Final Take​

AI-generated backends are fast to build. That makes fast, reliable debugging infrastructure even more important.

A truth-probe endpoint is one of the highest-leverage tools you can add:

• better incident response
• faster root cause isolation
• lower guesswork
• safer production decisions

Build it before the next incident, not during it.

If you only implement one thing this quarter, implement this.

Why burning more AI tokens does NOT mean your engineering team is more productive​

A strange new metric is spreading across the AI industry:

"How many tokens did your team consume this month?"

That sentence alone should worry every engineering leader.

If you are building the infrastructure behind this shift, the same pattern shows up across La Rebelion Labs, My Clawster, Clawne Me, and HAPI MCP.

Some companies are now treating AI token consumption as a proxy for innovation, productivity, or "AI maturity." Engineers are being ranked by usage. Internal dashboards celebrate massive token growth. Teams proudly announce billions of tokens processed as if compute consumption itself created business value.

The internet gave this trend a name:

Tokenmaxxing.

And honestly? The industry is dangerously close to repeating one of the oldest mistakes in software engineering history:

Rewarding activity instead of outcomes.

The core problem with tokenmaxxing​

The assumption behind tokenmaxxing sounds logical at first:

• More prompts → more AI usage
• More AI usage → more output
• More output → more productivity

But software engineering has already learned this lesson decades ago.

We once measured:

• lines of code,
• hours worked,
• ticket velocity,
• sprint points,
• story completion rates.

Every one of those metrics failed when teams optimized for the metric instead of the outcome.

AI tokens are becoming the modern version of "lines of code written."

And the consequences could be worse.

Because tokens directly translate into:

• infrastructure cost,
• inference latency,
• operational complexity,
• energy consumption,
• retry storms,
• and hidden architectural inefficiencies.

A company can burn millions of dollars in tokens and still ship low-quality products.

Or worse: Ship nothing meaningful at all.

The real bottleneck is NOT tokens​

Here is the uncomfortable truth many AI companies are avoiding:

Tokens are not the bottleneck.

Friction is.

That distinction changes everything.

The majority of token waste today is not caused by intelligence problems.

It is caused by:

• broken integrations,
• human-designed APIs,
• unreliable tools,
• authentication failures,
• brittle workflows,
• context reconstruction,
• and systems never designed for autonomous agents.

In other words:

AI agents are paying an operational tax just to exist inside human infrastructure.

The hidden "AI tax" nobody talks about​

Most enterprise systems were designed for humans:

• humans clicking buttons,
• humans reading dashboards,
• humans manually correcting failures,
• humans navigating ambiguous workflows.

AI agents inherit none of those advantages.

So what happens?

The agent retries.

Again. And again. And again.

Every retry burns:

• tokens,
• latency,
• compute,
• API quotas,
• and money.

Not because the AI is "thinking deeply."

But because the infrastructure itself is hostile to automation.

Example: the retry loop disaster​

Imagine an AI agent attempting to provision cloud infrastructure.

The workflow seems simple:

1. Read API documentation
2. Authenticate
3. Deploy resource
4. Verify deployment

But reality looks like this:

• API schema mismatch
• unclear error message
• OAuth token expired
• inconsistent documentation
• timeout response
• rate limiting
• partial state failure
• undocumented edge case

Now the agent:

• retries requests,
• rebuilds context,
• re-reads documentation,
• regenerates plans,
• and consumes thousands of additional tokens.

The organization sees:

"Wow, our AI usage is skyrocketing!"

But the truth is: the system is inefficient.

The tokens are smoke coming out of architectural friction.

Token consumption is becoming the wrong KPI​

This is where the industry is heading into dangerous territory.

If companies reward:

• token usage,
• AI interaction count,
• agent invocation frequency,
• or inference consumption,

then teams will optimize for those metrics.

That creates predictable dysfunction:

Engineers start optimizing for visibility​

Instead of:

• reducing friction,
• improving reliability,
• minimizing retries,
• simplifying workflows,

teams may unconsciously optimize for:

• more prompts,
• longer chains,
• more agent orchestration,
• inflated inference usage.

The metric becomes theater.

And theater scales fast in enterprise environments.

The AI industry is measuring the wrong thing​

The real question is not:

"How many tokens did your organization consume?"

The real question is:

"How much friction did your architecture eliminate?"

That is the metric nobody is measuring yet.

Because in the AI-native future: the winning systems will not be the ones consuming the most intelligence.

They will be the ones wasting the least intelligence.

The future belongs to low-friction architectures​

This is where the next generation of infrastructure becomes critical.

The AI ecosystem is still built on human-native assumptions:

• visual dashboards,
• manual workflows,
• click-based authentication,
• verbose documentation,
• disconnected APIs.

Agents struggle because they operate in environments optimized for humans.

This is exactly why protocol-driven ecosystems like Model Context Protocol, HAPI MCP and the runMCP marketplace matter.

Protocols reduce ambiguity.

And reducing ambiguity reduces token waste.

If you are implementing that layer, HAPI CLI is part of the same workflow for building and shipping MCP-driven systems.

Why MCP changes the equation​

The future is not: "bigger models consuming infinite tokens."

The future is: structured agent interoperability.

With MCP-style architectures:

• tools become discoverable,
• interfaces become predictable,
• context becomes standardized,
• retries decrease,
• orchestration simplifies,
• and agents stop wasting tokens interpreting chaos.

This is not merely an optimization improvement.

It is an economic shift.

The companies that win will optimize "cost-per-outcome"​

Today many organizations measure:

• tokens per user,
• AI usage growth,
• inference scale.

Tomorrow they will measure:

• cost per successful workflow,
• latency per completed task,
• retries per orchestration,
• token efficiency per business outcome.

That changes incentives dramatically.

Because suddenly:

• clean APIs matter,
• deterministic tooling matters,
• context engineering matters,
• observability matters,
• orchestration reliability matters.

The conversation moves from:

"How much AI are we using?"

to:

"Why is our AI wasting so much effort?"

That shift is also why My Clawster and Clawne Me focus on managed agent infrastructure instead of raw usage volume.

AI systems are exposing technical debt at massive scale​

This may become one of the most important lessons of the AI era:

AI agents amplify technical debt faster than humans ever could.

A human can compensate for:

• poor UX,
• unclear workflows,
• inconsistent naming,
• missing documentation.

Agents cannot.

They brute-force through confusion using tokens.

That means: every badly designed system becomes an inference cost multiplier.

The hidden tax compounds across:

• APIs,
• workflows,
• integrations,
• cloud tooling,
• enterprise software.

And most organizations are completely unprepared for this reality.

The rise of "friction engineering"​

A new discipline is emerging underneath all this:

Friction engineering.

Not prompt engineering.

Not even agent engineering.

Friction engineering is the practice of:

• minimizing ambiguity,
• reducing retries,
• simplifying orchestration,
• optimizing context flow,
• and designing systems AI can operate efficiently.

This becomes a business advantage because lower friction means:

• fewer tokens,
• lower cloud costs,
• faster workflows,
• better reliability,
• higher agent autonomy.

The organizations that master this will dominate the next decade of AI infrastructure.

Explore the ecosystem​

If you are building toward lower-friction AI systems, these related projects expand on the ideas in this post:

• La Rebelion Labs
• HAPI MCP
• HAPI CLI
• runMCP Marketplace
• My Clawster
• Clawne Me

Ideas to reduce the "AI tax" in modern architectures​

Here are practical strategies engineering teams should prioritize immediately.

1. Build machine-first APIs​

Most APIs are still human-first.

Agents need:

• deterministic responses,
• structured error handling,
• predictable schemas,
• semantic consistency.

A beautiful dashboard means nothing to an autonomous agent.

2. Reduce retry loops aggressively​

Track:

• retry frequency,
• context rebuilds,
• failed orchestration chains,
• redundant inference calls.

These are hidden token leaks.

Retries are the new memory leak.

3. Create persistent agent memory layers​

Agents repeatedly relearn workflows because context windows reset.

Persistent memory systems reduce:

• repeated reasoning,
• repeated tool discovery,
• repeated planning.

That directly lowers token consumption.

4. Optimize for orchestration clarity​

Many workflows fail because:

• tool descriptions are vague,
• capabilities overlap,
• APIs behave inconsistently.

Agents need explicit operational contracts.

5. Build observability for agent friction​

Most observability stacks track:

• CPU,
• latency,
• infrastructure health.

Very few track:

• token waste,
• reasoning loops,
• failed tool selection,
• context churn.

That visibility will become essential.

6. Standardize protocols​

Every custom integration increases:

• ambiguity,
• translation layers,
• orchestration complexity.

Protocols like MCP reduce operational entropy.

That lowers the AI tax.

Final thought​

The AI industry is entering its "vanity metric phase."

Right now many organizations celebrate:

• token growth,
• inference scale,
• AI usage volume.

But eventually the market will mature.

And when it does, the winners will not be the companies consuming the most intelligence.

They will be the companies building systems where intelligence flows with the least resistance.

Because the future of AI infrastructure is not about maximizing tokens.

It is about minimizing friction.

And that changes the entire game.

The $1.3 Million AI Bill Is Not the Story. Agent Infrastructure Is.​

603 billion tokens. 7.6 million requests. Around $1.3 million in OpenAI API spend in 30 days.

That headline is making rounds across the AI community after Peter Steinberger shared the operational cost of running around 100 Codex instances in the cloud. According to Peter, simply disabling “fast mode” could reduce costs by roughly 70%.

Most people looked at the number and thought:

“That’s insane.”

I looked at it and thought:

“This is what the future of software infrastructure looks like.”

Because the real story is not the bill.

The real story is this:

We are entering the era of AI agent infrastructure.

And most companies are still thinking about AI as if it were just a chatbot.

Enterprises Are Not Going to Run One Agent​

For the last two years, most conversations around AI focused on:

• chat interfaces
• copilots
• prompt engineering
• model benchmarks
• LLM providers

But something bigger is quietly happening underneath.

Organizations are starting to move from:

• single AI assistants → toward
• fleets of specialized agents

That changes everything.

The moment you move from:

• “one assistant” to
• “hundreds of autonomous or semi-autonomous execution units”

...you suddenly inherit the same operational challenges we already experienced in:

• cloud computing
• Kubernetes
• microservices
• DevOps
• platform engineering

Except now:

• the workloads are probabilistic
• the execution paths are dynamic
• the context windows are expensive
• and every token has a cost

AI is no longer just a UX problem.

It is becoming an infrastructure discipline.

My Reality Check: Spending $20 Felt Expensive​

Sometimes I look at my own side-project AI spending — around $20 Pro Plan plus APIs — and think:

“This is getting expensive.”

Then I see someone operating 100 coding agents consuming enterprise-scale token budgets and realize:

We are still early.

Very early.

The economics of AI agents will force companies to rethink:

• architecture
• governance
• orchestration
• observability
• execution efficiency
• runtime isolation
• and trust boundaries

Because the problem is not:

“Can AI work?”

The problem is:

“Can AI scale operationally and economically?”

That is a very different conversation.

The Hidden Problem Nobody Talks About​

Most AI demos today show:

• one prompt
• one agent
• one response

Reality will look more like this:

User Request
   ↓
Planner Agent
   ↓
Security Validation Agent
   ↓
API Discovery Agent
   ↓
Execution Agent
   ↓
Code Review Agent
   ↓
Compliance Agent
   ↓
Monitoring Agent
   ↓
Human Approval

Now multiply that by:

• departments
• regions
• customers
• workflows
• environments
• tenants
• business units

Suddenly:

• 10 agents becomes normal
• 100 agents becomes expected
• 1000+ agents becomes realistic

At that scale, enterprises will need answers for questions like:

Governance​

Who approved this execution?

Traceability​

Which agent triggered the API call?

Security​

What permissions did the agent have?

Cost Visibility​

Which workflow consumed the most tokens?

Context Efficiency​

Why are we injecting 500 tools into every context window?

Runtime Isolation​

Can this agent access production systems?

Compliance​

Can we audit the entire execution chain?

These are not chatbot questions anymore.

These are infrastructure questions.

Kubernetes Solved Compute Orchestration. What Solves Agent Orchestration?​

This is where I believe the industry is heading next.

Kubernetes helped us orchestrate:

• containers
• workloads
• networking
• policies
• scaling

But AI agents introduce an entirely new operational layer.

Agents need:

• identity
• memory boundaries
• execution policies
• tool governance
• workflow orchestration
• observability
• lifecycle management
• context optimization
• trust frameworks

In other words:

AI Agents need platform engineering.

And I believe this will become one of the biggest categories in enterprise infrastructure over the next few years.

Why I Started Building “My Clawster”​

This realization is exactly what pushed me to start building My Clawster.

At first, it was a simple idea:

“What if AI agents were treated more like governed infrastructure workloads?”

But the deeper I explored the problem, the more obvious it became: the industry needs more than “another chatbot UI.”

It needs:

• orchestration
• governance
• execution reliability
• agent lifecycle management
• policy enforcement
• runtime isolation
• observability
• discoverability

That’s where concepts like:

• clusters of agents
• managed execution
• governed APIs
• specialized personas
• isolated runtimes
• Skills
• MCP servers
• execution traces start becoming critical.

“Clawne Me”: Dogfooding the Future​

One of the most interesting experiments I’ve been running internally is called Clawne Me.

The idea is simple:

Create specialized instances of yourself.

Not literally.

But operationally.

Different personas. Different contexts. Different responsibilities. Different execution boundaries.

For example:

• architecture persona
• DevOps persona
• product strategy persona
• research persona
• content persona

Each one optimized for:

• different tools
• different context windows
• different permissions
• different execution flows

This is where the conversation gets fascinating.

Because enterprises are not going to deploy:

“One AI employee.”

They will deploy:

“Entire organizations of specialized agents.”

And those organizations will require:

• governance
• structure
• security
• orchestration
• operational controls

Exactly like cloud-native systems did.

The Real Cost Problem Is Not Tokens​

The industry keeps obsessing over:

• token pricing
• model costs
• inference economics

Those matter.

But they are not the biggest long-term problem.

The biggest problem is inefficient orchestration.

Examples:

• duplicated context
• oversized prompts
• unnecessary tool injection
• uncontrolled execution loops
• recursive workflows
• ungoverned retries
• context bloat
• poor agent routing

That is why:

• observability
• runtime governance
• Skills
• deterministic orchestration
• execution policies
• progressive tool disclosure

...will become foundational patterns.

The future winners will not necessarily be the companies with the smartest model.

They may be the companies with the most efficient AI infrastructure.

AI Infrastructure Is Becoming the New DevOps​

A few years ago, companies realized:

• deploying servers manually does not scale
• unmanaged cloud infrastructure becomes chaos
• governance matters
• observability matters
• platform engineering matters

We are about to repeat the same cycle with AI agents.

Today:

• AI feels magical
• experimentation is easy
• everyone is building demos

Tomorrow:

• AI budgets will explode
• governance requirements will hit
• security teams will step in
• compliance teams will demand auditability
• platform teams will need orchestration layers

And that’s when the industry will realize:

AI Agents are infrastructure workloads.

Not just chat experiences.

Final Thoughts​

The $1.3 million API bill is shocking.

But it is also a preview.

A preview of what happens when AI moves from:

• experimentation → to
• production infrastructure

The companies that win the next wave of AI will not only have:

• better prompts
• bigger models
• nicer UIs

They will have:

• governed execution
• scalable orchestration
• trusted runtimes
• efficient context management
• operational visibility
• secure agent ecosystems

That future is closer than most people think.

And honestly?

That’s exactly why I started building:

• My Clawster
• Clawne Me
• HAPI MCP
• Skills-driven orchestration

Because I believe the next evolution of AI is not:

“Talking to AI.”

It is:

“Operating AI systems at scale.”

References​

• Peter Steinberger’s original post
• The Decoder’s coverage
• Tom’s Hardware coverage

Be HAPI and Go Rebels! ✊🏽

What surprised me recently is that Codex can generate images too, directly from your editor.

This feature is still flying under the radar, but it completely changed part of my content workflow.

I started using Codex to create banner images for my blog posts, and honestly, it removed an entire layer of friction from my process.

Before this, I had built a custom Skill that generated blog banners using SVG templates and a puppeteer rendering pipeline. Technically, it worked. But the workflow felt fragile:

• Generate the SVG
• Run the rendering script
• Tweak styles manually
• Re-render until it looked acceptable

The biggest problem was quality. The images looked generic and lacked the visual impact I wanted for my blog. I had to spend extra time tweaking the SVG templates and styles to get something that felt right.

Now I can stay inside my editor, describe what I want in natural language, and let Codex generate production-ready visuals in seconds.

No switching tools. No rendering scripts. No fighting with SVG layouts.

Just prompt → image.

That alone makes the feature worth exploring.

What Codex Image Generation Can Do​

Codex is not limited to code generation anymore.

You can now ask it to create or edit images directly from your development environment. That makes it surprisingly useful for:

• Blog post banners
• UI mockups
• Hero sections
• App illustrations
• Placeholder assets
• Sprite sheets
• Layout concepts
• Social media graphics
• Documentation visuals

You can also provide a reference image and ask Codex to transform, extend, or restyle it.

For developers working on frontend systems, design systems, internal tools, or content platforms, this becomes a massive productivity boost because the feedback loop becomes almost instant.

Instead of opening multiple tools just to create a quick visual asset, you stay focused inside the same workflow.

Natural Language Prompts Work Surprisingly Well​

The best part is that you do not need to learn a complex syntax.

You can simply describe what you want:

"Create a modern cyberpunk banner for a cloud engineering article with neon purple lighting and minimal typography."

Or explicitly invoke the image generation skill using:

$imagegen

That tells Codex to switch into image-generation mode directly.

The results are much better than I expected for something integrated into a coding workflow.

How to Enable Image Generation in Codex​

Depending on your setup, image generation may still be behind an experimental feature flag.

To enable it manually, update your configuration file:

[features]
image_generation = true

File location:

~/.codex/config.toml

You can also enable it directly from the CLI:

codex features enable image_generation

Once enabled, you can start generating images immediately by:

• Using $imagegen
• Asking naturally in prompts
• Providing reference images for edits or transformations

Why This Matters More Than It Seems​

At first glance, image generation inside Codex feels like a "nice extra feature."

It is not.

This is another example of development environments becoming multimodal.

The editor is evolving from:

• "a place where you write code"

into:

• "a workspace where you build entire products."

Code, visuals, documentation, UI ideas, and content generation are starting to happen in the same interface.

That changes workflows significantly.

For solo builders, startup founders, DevRel engineers, technical writers, and indie hackers, this removes operational overhead that usually breaks momentum.

The biggest productivity gains in AI are not always about replacing difficult work.

Sometimes they come from removing tiny interruptions repeated hundreds of times.

This is one of those cases.

Final Thoughts​

I originally discovered this feature while trying to improve my blog banner workflow.

I expected a small convenience feature.

What I found instead was a surprisingly practical capability that eliminated an entire mini-pipeline from my content system.

If you already use Codex daily, image generation is worth testing immediately.

Especially if your workflow sits at the intersection of:

• engineering
• content creation
• UI work
• documentation
• startup building

The less context switching you do, the faster ideas become real artifacts.

And that is where these tools start becoming genuinely transformative.

Go Rebeles! ✊🏽

Most people think they are building "just another tool."

Then one day they wake up and realize:

"Wait... this thing became an ecosystem."

That is exactly what is happening at La Rebelion Labs.

And honestly?

I did not fully plan it that way.

I started building because I love solving problems:

• Kubernetes in airgapped environments
• API-driven automation
• MCP infrastructure
• AI tooling
• developer experience
• agent orchestration
• platform engineering

But little by little, the projects started connecting together, and the ecosystem started growing.

• HAPI MCP
• GYAT
• OrcA
• QBot
• My Clawster
• Clawne Me
• Skills
• Rebel U
• and more...

At some point, I realized:

"I'm not building isolated tools anymore."

I am accidentally building an AI platform ecosystem.

And I'm doing it in the open.

Why This Matters​

The AI industry is moving extremely fast.

Every week:

• new frameworks appear
• new protocols emerge
• new "agent platforms" get funded
• companies reinvent the same infrastructure

But most people are still missing something important:

AI Needs Infrastructure​

Not just prompts.

Not just models.

Not just agents.

Infrastructure.

The same way cloud computing needed:

• Kubernetes
• APIs
• gateways
• orchestration
• observability
• governance

AI agents now need:

• execution layers
• orchestration runtimes
• Skills
• APIs
• MCP servers
• governance
• identity
• routing
• operational controls

That is the layer I am building.

Built by a Practitioner, Not a VC Deck​

La Rebelion Labs was never created as a "startup idea."

It came from years of:

• enterprise architecture
• platform engineering
• DevOps
• Kubernetes
• automation
• APIs
• cloud-native systems
• real operational pain

Especially in:

• enterprise
• telco
• airgapped
• regulated environments

The goal was always simple:

Build practical infrastructure that helps engineers and organizations survive the next wave of complexity.

Now that wave is AI agents.

Why Some Projects Are Open and Others Are Not​

This is where I want to be transparent.

Some projects at La Rebelion Labs are fully open.

Others are source-available.

Others are proprietary SaaS.

Why?

Because I need to balance:

• innovation
• sustainability
• community access
• ecosystem growth
• and survival

And yes...

Coffee helps. You can buy me one here, by the way. Or sponsor La Rebelion here.

But infrastructure projects run on more than caffeine.

They run on:

• time
• support
• infrastructure costs
• experimentation
• iteration
• failures
• documentation
• support requests
• debugging
• long nights

That is why community support matters so much.

The Truth: Community Support Is My Triple-Shot Espresso​

I love building in public.

I love teaching.

I love experimenting.

But the reality is:

Community support is the fuel that allows this ecosystem to continue evolving.

Every membership helps:

• keep projects alive
• improve documentation
• build tutorials
• create courses
• fund experimentation
• support infrastructure costs
• accelerate development

You are not "buying access."

You are helping build:

• an independent AI infrastructure ecosystem
• outside the traditional VC-only model
• built by engineers for engineers

That matters to me deeply.

Wait... Is This Open Source?​

Some parts are.

Some are not.

And that distinction matters.

Open Source​

Some components are licensed under permissive licenses like:

• Apache 2.0
• MIT

These are intended to:

• spread adoption
• encourage integrations
• grow the ecosystem

Examples:

• SDKs
• examples
• developer tooling
• adapters

Source-Available​

Some projects are source-available under the:

La Rebelion Labs Community License (LRL-CL)​

This means:

• members can access the source code
• learn from it
• modify it
• self-host it
• experiment with it

But:

• redistribution is not allowed
• resale is not allowed
• public reposting is not allowed
• large-scale enterprise use requires commercial licensing

Why?

Because if I fully open-source everything:

• the ecosystem becomes difficult to sustain
• enterprise extraction becomes easy
• and the projects eventually die

Unfortunately, many infrastructure founders learn this too late.

The Reality of Modern AI Infrastructure​

AI infrastructure is expensive to build.

Especially:

• orchestration layers
• agent runtimes
• workflow engines
• MCP infrastructure
• Skills systems
• hosted control planes

These are not weekend toy projects anymore.

They are becoming:

• operational platforms
• runtime infrastructure
• enterprise systems

And enterprises derive enormous value from them.

That is why modern infrastructure companies evolved toward:

• open-core
• source-available
• commercial licensing

Examples include:

• Redis Licensing
• Elastic Licensing
• CockroachDB Licensing FAQ
• Sentry Licensing Model

The goal is not greed.

The goal is sustainability.

The La Rebelion Labs Philosophy​

My philosophy is simple:

Keep the ecosystem accessible.​

Keep innovation alive.​

Prevent abusive extraction.​

Protect sustainability.​

That is the balance I am trying to achieve.

The License​

Below is the current version of the:

La Rebelion Labs Community License (LRL-CL)​

La Rebelion Labs Community License (LRL-CL)
Version 1.0
Copyright (c) 2026 La Rebelion Labs

By accessing, downloading, using, or modifying this software, you agree to the terms of this License.

1. Definitions

"Software" means the source code, binaries, assets, documentation, configuration, workflows, examples, templates, and related materials distributed under this License.

"Licensor" means La Rebelion Labs and its contributors.

"User" means an individual or organization accessing or using the Software.

"Community Member" means a user with authorized access through La Rebelion Labs memberships, subscriptions, partnerships, or approved distribution channels.

2. Grant of Rights

Subject to the terms and restrictions of this License, Community Members are granted a limited, non-exclusive, non-transferable, revocable license to:

- Access and use the Software
- Modify the Software for internal or personal purposes
- Self-host the Software
- Learn from and experiment with the Software
- Build internal solutions using the Software

3. Restrictions

You may NOT, without prior written permission from the Licensor:

- Redistribute the Software
- Share the source code publicly or privately outside authorized Community Members
- Publish the Software to public repositories
- Sell, sublicense, rent, lease, or commercially distribute the Software
- Offer the Software as a hosted or managed service
- Create competing commercial products or services based substantially on the Software
- Remove or alter copyright notices, branding, or license text
- Circumvent access restrictions, licensing systems, or membership protections

4. Contributions

Unless otherwise agreed in writing, any contributions submitted to the Licensor may be used, modified, redistributed, or relicensed by the Licensor without obligation or compensation.

5. Ownership

The Software is licensed, not sold.

All intellectual property rights, title, and ownership remain exclusively with the Licensor.

6. Termination

This License terminates automatically if you violate any term of this License.

Upon termination, you must immediately stop using and distributing the Software and delete all copies in your possession.

7. No Warranty

THE SOFTWARE IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AVAILABILITY, OR PERFORMANCE.

8. No Liability

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE LICENSOR SHALL NOT BE LIABLE FOR ANY CLAIMS, DAMAGES, LOSSES, OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT, OR OTHERWISE, ARISING FROM OR RELATED TO THE SOFTWARE OR ITS USE.

9. Governing Terms

This License constitutes the complete agreement between the User and the Licensor regarding the Software.

The Licensor reserves the right to publish updated versions of this License for future releases of the Software.

Using the Software after receiving updated versions constitutes acceptance of the updated terms.

10. Contact

Licensing inquiries:
https://rebelion.la

Commercial licensing and enterprise partnerships:
https://mcp.com.ai  
https://clawster.my

11. Production and Commercial Use Limitations

Use of the Software in production environments requires a commercial license if ANY of the following conditions apply:

- The organization has more than 25 employees
- The Software manages more than 10 active agents, runtimes, or orchestrated workloads
- The Software processes more than 100,000 monthly requests, executions, or workflows
- The organization generates more than $1,000,000 USD in annual revenue
- The Software is used as part of a commercial hosted or managed service

For commercial licensing inquiries:
https://rebelion.la

The Bigger Vision​

I genuinely believe:

• APIs
• MCP
• Skills
• AI orchestration
• and managed agent infrastructure

are becoming foundational layers of the next generation of software.

And I want La Rebelion Labs to help shape that future.

Not behind closed doors.

But openly. With the community. Together.

Final Thoughts​

If you are already supporting La Rebelion Labs: thank you.

Seriously.

You are helping keep independent engineering alive.

And if you are considering becoming part of the community:

thank you for helping fuel this crazy experiment.

Because yes...

Innovation may be in my DNA.

But community support is the triple-shot espresso keeping the ecosystem alive.

“Just install an agent and let it work.”

That may work for demos. It does not work for enterprises.

As AI agents become part of engineering, operations, support, DevOps, security, and business workflows, companies are about to face a new challenge:

How do you securely manage agents at scale?​

That question pushed me to start building something bigger than a simple AI tool.

It started with APIs. Then MCPs. Then Skills. Then agents.

Now, the next layer is becoming obvious:

Managed Agent Infrastructure

And that is exactly why I created My Clawster.

The Shift Nobody Is Talking About

For years, APIs were designed for humans and applications.

Now they are becoming the execution layer for AI agents.

That changes everything.

Agents no longer need traditional interfaces. They need:

• APIs
• MCP servers
• Skills
• Execution environments
• Secure access
• Runtime isolation
• Governance
• Observability

The problem is that most organizations are approaching this the wrong way.

They are installing agents directly on laptops, workstations, or shared environments without proper isolation.

That is the beginning of a new era of Shadow IT.

Or even worse:

Shadow Agents

And enterprises already know how painful uncontrolled automation can become.

APIs + MCPs + Skills + Agents = My Clawster

Before building My Clawster, I spent months working on the foundations.

That foundation became the HAPI MCP stack.

The original goal was simple:

Turn existing APIs into AI-ready systems without forcing companies to rewrite everything.

That led me to create a workflow where developers can expose APIs as MCP servers with minimal friction and near-zero custom MCP coding.

Instead of rebuilding systems for AI, organizations can leverage the APIs they already own.

But exposing APIs was only the first step.

The next realization came quickly:

If APIs are becoming tools for agents, then enterprises need a control plane for agents.​

That is where My Clawster enters the picture.

What Is My Clawster?

My Clawster is a managed agent infrastructure platform.

Think of it as a control plane for AI agents running across:

• Virtual Machines
• Kubernetes clusters
• Hybrid environments
• On-premise infrastructure
• Airgapped environments
• Cloud deployments

The idea is simple:

Instead of installing unmanaged agents everywhere, organizations deploy isolated and controlled “Claws.”

Each Claw is an isolated runtime capable of executing agent tasks securely.

A collection of Claws becomes a:

Clawster

The architecture is designed around:

• Agent isolation
• Workspace separation
• Secure execution
• Sandboxing
• Team governance
• Enterprise-ready deployment models
• API-first automation
• Hybrid and on-prem support

Because enterprises are not asking:

“Can agents work?”

They are asking:

“How do we safely operate agents in production?”

Meet Clawne Me

While building My Clawster, I also created another project:

Clawne Me

Clawne Me is essentially a personal or lightweight deployment model for the same ecosystem.

A “Clawne” automatically provisions an isolated Claw instance.

You can think about it as:

A single-node personal Clawster.

The vision behind Clawne Me is to simplify access to managed agents for:

• Solopreneurs
• Developers
• Creators
• Technical teams
• AI enthusiasts
• Small businesses

Provisioning and activation are automated through My Clawster.

The long-term vision is to allow users to spin up isolated agent runtimes as easily as deploying an application.

Why Sandboxing Matters for AI Agents

One thing is becoming increasingly clear:

Agents should never run without isolation.​

Especially in enterprise environments.

An unrestricted agent with filesystem access, shell access, credentials, browser sessions, and APIs can become a serious operational and security risk.

This is why My Clawster focuses heavily on:

• Isolation boundaries
• Controlled execution
• Workspace-level permissions
• Project separation
• Runtime governance
• Controlled access to tools and APIs

The future of AI infrastructure is not just about intelligence.

It is about:

Controlled Intelligence

Underneath the Stack

Underneath My Clawster and Clawne Me, several technologies are already working together.

The ecosystem currently includes:

• HAPI MCP
• OpenClaw
• Hermes
• Skills
• MCP servers
• APIs
• Kubernetes-native orchestration
• VM-based execution environments

The goal is not to create “yet another AI app.”

The goal is to create infrastructure.

Infrastructure that respects:

• Existing enterprise systems
• Existing APIs
• Existing security models
• Existing governance processes

Instead of forcing companies to rebuild everything from scratch for AI adoption.

The Future Is Not AI Apps

The future is:

Managed Agent Infrastructure

Organizations will eventually operate fleets of agents the same way they operate:

• Kubernetes clusters
• CI/CD pipelines
• APIs
• Service meshes
• Cloud infrastructure

And just like cloud-native changed infrastructure management, managed agent infrastructure will change how organizations deploy intelligence.

The companies that win in the next phase of AI will not necessarily be the ones with the biggest models.

They will be the ones that can:

• Govern agents
• Scale agents
• Secure agents
• Observe agents
• Control agents
• Integrate agents safely into existing operations

That is the future I am building toward with My Clawster.

Final Thoughts

The AI industry is still heavily focused on demos.

But production environments require a completely different mindset.

Enterprises need:

• Isolation
• Governance
• Observability
• Security
• Lifecycle management
• Runtime orchestration
• Standardized integration patterns

That is where managed agents evolve from “cool experiments” into real infrastructure.

And honestly?

I think we are only at the beginning.

Frequently Asked Questions (FAQ)​

What is My Clawster?​

My Clawster is a managed agent infrastructure platform designed to orchestrate isolated AI agent runtimes across Kubernetes, VMs, hybrid, and on-prem environments.

What problem does My Clawster solve?​

It helps organizations securely manage, isolate, govern, and orchestrate AI agents instead of deploying unmanaged agents directly into enterprise environments.

What is Clawne Me?​

Clawne Me is a lightweight personal deployment model that provisions isolated single-agent runtimes automatically.

What is HAPI MCP?​

HAPI MCP is an API-first framework designed to expose APIs as MCP servers with minimal friction, enabling AI agents to interact with existing systems safely and efficiently.

Why is sandboxing important for AI agents?​

Sandboxing reduces security risks by isolating agent execution environments, controlling permissions, and limiting access to sensitive systems and resources.

Can My Clawster run on-premise?​

Yes. My Clawster is being designed for hybrid, cloud, and fully on-premise deployments, including regulated and airgapped environments.

Every technical founder, architect, DevOps engineer, or creator eventually hits the same problem:

You have brilliant ideas... at the worst possible time.

Driving. Walking. Cooking. At the gym. In the middle of debugging something.

And by the time you sit in front of your laptop?

The idea is gone.

Or worse: You remember just enough to know it was good.

That used to happen to me constantly.

As someone building projects like HAPI MCP, My Clawster, and multiple content platforms, I realized something important:

The bottleneck is not ideas anymore.

The bottleneck is capturing and operationalizing them fast enough.

That is why I started experimenting with local AI transcription workflows. I was struggling to capture my best thinking and turn it into reusable content. I needed a way to quickly transcribe voice notes and then clean them up for production use.

I found a tool that completely changed how I capture technical thinking, content ideas, architecture discussions, and operational knowledge. It is called Vibe, and it is a local-first AI transcription tool powered by Whisper models!

Vibe on GitHub

Why Local AI Transcription Matters More Than People Think​

Most people think transcription tools are only for meetings or podcasts.

That is massively underestimating the value.

If you are a:

• Developer
• Platform engineer
• Technical Product Manager
• Founder
• Content creator
• DevOps engineer
• Architect
• AI builder

...your voice notes are probably one of your most valuable assets. If you don't capture them, they disappear. Because your best insights rarely happen while sitting perfectly organized in Notion or any other note-taking app.

They happen in motion.

The challenge is turning:

• messy thoughts
• fragmented explanations
• troubleshooting sessions
• architecture reasoning
• random innovation sparks

...into structured, reusable, searchable material.

That is where local AI tools like Vibe become game changers.

What Is Vibe?​

Vibe GitHub Repository

Vibe is a local-first AI transcription tool powered by Whisper models.

What makes it special?

Key Benefits​

1. Local Processing​

Your audio stays on your machine.

This is huge for:

• enterprise environments
• regulated industries
• confidential architecture discussions
• customer-sensitive information
• airgapped workflows
• zero-trust environments

As someone who works heavily with enterprise and airgapped systems, this immediately caught my attention.

2. Surprisingly Accurate​

Even with technical language.

I tested it with:

• Kubernetes concepts
• MCP terminology
• API-first discussions
• infrastructure conversations
• architecture brainstorming

And the results were impressive.

Especially compared to traditional cloud transcription services.

3. Perfect for "Thinking Out Loud"​

This is the killer feature.

You do not need polished audio.

You can literally:

• record yourself walking
• brainstorm ideas verbally
• explain architectures casually
• dump raw thoughts

Then later:

• clean the transcript

• organize ideas

• transform them into:

  • blog posts
  • PRDs
  • LinkedIn posts
  • tutorials
  • technical documentation
  • operational runbooks

My Real Workflow Using Vibe​

This is where things become practical.

Here is my current workflow.

Step 1 — Record Everything​

I stopped trying to "remember later."

Instead:

• I record quick audio notes
• architecture thoughts
• debugging discoveries
• product ideas
• content hooks
• system designs

Sometimes they are 30 seconds.

Sometimes 15 minutes.

The important part: Capture first. Organize later.

Step 2 — Transcribe Locally with Vibe​

Using Vibe, I generate transcripts locally.

This gives me:

• searchable knowledge
• reusable technical thinking
• content seeds
• documentation drafts

And because it is local-first:

• no vendor lock-in
• no API costs
• no privacy concerns
• no token usage explosion

That matters more than people realize.

Especially if you are building an AI-heavy workflow.

Step 3 — Clean the Transcript​

The raw transcript becomes the foundation.

Then I:

• remove filler words
• improve structure
• split ideas into sections
• identify hooks
• extract insights

This transforms chaotic voice notes into structured knowledge.

Step 4 — Production-Ready Material​

This is where the magic happens.

One voice note can become:

This dramatically increases leverage.

Why This Workflow Is Powerful for Technical Professionals​

Most engineers underestimate something:

Your thinking process itself is valuable.

Not just the final code.

Your:

• debugging logic
• architecture decisions
• tradeoff analysis
• system reasoning
• operational discoveries

...all contain valuable intellectual property.

The problem is: Most of it disappears.

Voice-to-knowledge workflows solve that.

Local AI Is Quietly Becoming a Superpower​

There is another important trend happening here.

More creators and engineers are moving toward:

• local AI
• local LLMs
• offline tooling
• private workflows
• edge AI
• self-hosted productivity

Why?

Because relying entirely on SaaS AI platforms creates friction:

• recurring costs
• privacy concerns
• API dependency
• vendor lock-in
• unpredictable pricing
• latency

Tools like Vibe represent a different direction:

AI that works for you locally.

And honestly?

I think this trend is only getting started.

OK, now you may be thinking:

How to Install Vibe​

You can find the official project here:

Vibe GitHub Repository

The repository contains installation instructions for multiple platforms.

The setup is relatively straightforward.

Once installed:

1. Record your audio
2. Feed it into Vibe
3. Generate transcript
4. Clean the content
5. Repurpose it into production-ready material

Simple idea. Massive leverage.

Real Use Cases for Engineers and AI Builders​

Technical Documentation​

Explain systems verbally instead of manually typing everything from scratch.

Incident Retrospectives​

Record your debugging journey immediately after solving an issue.

You will capture insights that normally disappear.

Content Creation​

Transform voice notes into:

• blogs
• LinkedIn posts
• tutorials
• YouTube scripts
• newsletters

MCP and Agent Workflows​

Voice notes can become:

• prompts
• skills
• workflow instructions
• operational procedures
• agent memory seeds

This becomes incredibly powerful when combined with AI agents.

The Bigger Lesson Here​

The real value is not transcription.

The real value is:

Converting transient thinking into reusable systems.​

That is the actual unlock.

Most people consume AI.

Builders operationalize it.

Final Thoughts​

I genuinely think workflows like this are underrated.

Especially for:

• technical founders
• engineers
• creators
• architects
• AI builders

The ability to rapidly transform ideas into structured knowledge creates an unfair advantage over time.

And because tools like Vibe run locally, they align perfectly with:

• privacy
• ownership
• AI independence
• enterprise requirements
• airgapped workflows

If you constantly record ideas on the go, this tool is absolutely worth exploring.

Resources​

• Vibe GitHub Repository
• Whisper by OpenAI

Bonus: Automate the Workflow with Skills​

After experimenting with this workflow, I created a Skill to automate parts of the process:

• transcript cleanup
• formatting
• content preparation
• production-ready transformations

You can download them here:

👉 [DOWNLOAD LINK HERE]

Go Rebels ✊🏼

Maybe it started as a side project. Maybe it was a customer portal, an internal dashboard, a marketplace, a registry, a billing screen, or an admin console. It has routes, components, mock data, styles, a few clever helpers, and just enough product thinking to feel real.

Then the second product shows up.

Now you want that same capability inside another app.

The first instinct is understandable: "Can I just import the app?"

Short answer: yes, technically. Better answer: almost never as the default.

If you import a full React app into another React app, you usually import more than screens. You import its router, providers, CSS assumptions, auth decisions, environment variables, dependency versions, and deployment model. That is how a reusable feature becomes a hidden maintenance contract.

The better pattern is this:

Turn the reusable capability into packages, then keep each deployed app as a thin shell.

That is the difference between copying a product and extracting a product capability.

The Real Problem​

Creators do not struggle because they lack code. They struggle because they have working code in the wrong shape.

An app is usually optimized for launch:

• Render a root component.
• Own the router.
• Load global CSS.
• Fetch or mock data directly.
• Control layout and navigation.
• Assume one deployment target.

That is great when the app is the product.

It becomes painful when the app needs to become part of a larger platform.

The moment you embed it somewhere else, the host app already has opinions:

• It already owns authentication.
• It already owns BrowserRouter.
• It already has a design system.
• It already has global layout and navigation.
• It already uses one React instance.
• It already has build tooling, Tailwind config, environment variables, and route protection.

When two apps both try to be the root, the integration gets weird fast.

The Challenges Nobody Mentions Early Enough​

The hard part is not moving files. The hard part is separating responsibilities.

1. Routing Conflicts​

A standalone app usually creates its own router:

createRoot(document.getElementById("root")!).render(
  <BrowserRouter>
    <App />
  </BrowserRouter>,
);

That is correct for a deployed app. It is wrong for a reusable feature package.

When the feature is embedded, the host should own the router:

<Route
  path="/marketplace/*"
  element={<MarketplaceRoutes basePath="/marketplace" />}
/>

The feature should export routes. It should not render the root.

2. Duplicated Providers​

Auth, theme, analytics, telemetry, error boundaries, data clients, and feature flags usually belong to the host app.

The embedded feature should receive what it needs through props or context:

<MarketplaceRoutes
  basePath="/marketplace"
  client={marketplaceClient}
  getAccessToken={getAccessToken}
  flags={{ checkoutEnabled: true }}
/>

This keeps the feature reusable without letting it hijack the platform.

3. Multiple React Copies​

This one is sneaky.

If your feature package declares react and react-dom as normal dependencies, you can accidentally bundle a second React copy. That leads to broken hooks, strange context behavior, and bugs that look impossible.

Reusable React packages should usually use peer dependencies:

{
  "peerDependencies": {
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "react-router-dom": "^7.0.0"
  }
}

The host app provides React. The package uses it.

4. CSS and Tailwind Drift​

Two apps can both use Tailwind and still be incompatible.

One might use Tailwind v3 with tailwind.config.js and PostCSS. Another might use Tailwind v4 with @tailwindcss/vite, @import "tailwindcss";, CSS @theme, and @source.

In a monorepo, the host app must scan the feature package source:

@import "tailwindcss";

@source "../../packages/feature-marketplace/src";

@theme {
  --color-brand: #1193b0;
  --radius-card: 0.5rem;
}

The feature package should avoid global resets and app-level CSS side effects. Let the shell own global styling.

5. Mock Data Coupling​

Most useful apps start with mock data. That is fine.

The problem is when pages import mock data directly:

import { apps } from "../data/mock-apps";

That makes the UI harder to reuse because the data source is wired into the screen.

Extract the model first:

packages/
  marketplace-domain/
    src/index.ts

Then create a client contract:

packages/
  marketplace-api-client/
    src/index.ts

Now the UI can render from a client, not from hardcoded data.

The Decision Model​

Use this when deciding how to reuse one app inside another:

This model keeps the architecture honest.

If you only need buttons, types, or clients, do not ship a whole app.

If you need complete screens, create a feature package.

If you need independent deployment, create an app shell that imports the feature package.

If you need independently deployed teams composing at runtime, then consider micro-frontends or Module Federation. But do not start there just because the code lives in two apps.

The Recommended Shape​

For a React, Vite, Bun, and Tailwind workspace, this structure works well:

repo/
  apps/
    web/
    marketplace/                 # thin standalone shell, if independent deployment is required
  packages/
    marketplace-domain/          # types, schemas, constants, validation
    marketplace-api-client/      # typed frontend-safe client
    feature-marketplace/         # reusable React pages, components, routes
    marketplace-db/              # schema and migrations, if reusable

The important idea is simple:

• Packages contain reusable capability.
• Apps contain runtime ownership.

That means apps/web can mount the marketplace under /marketplace/*, while apps/marketplace can still deploy the same feature independently.

Both apps consume the same feature package.

How to Integrate One React App Into Another​

Here is the sequence I recommend.

Step 1: Inventory the Source App​

Before moving code, identify each layer:

• Domain types and constants.
• Mock or seed data.
• API calls.
• UI primitives.
• Feature pages.
• Layout components.
• Router and app bootstrap.
• Global CSS.
• Static assets.
• Database schema or migrations.

You are not just moving folders. You are deciding ownership.

Step 2: Extract the Domain Package First​

Start with the code that has no React dependency.

Good candidates:

• Catalog models.
• Publisher models.
• Pricing plans.
• Deployment states.
• Validation helpers.
• Shared constants.

Example:

export type MarketplaceApp = {
  id: string;
  slug: string;
  name: string;
  summary: string;
  publisher: Publisher;
  pricing: PricingPlan[];
  deployment: DeploymentOption[];
};

This package should be boring. Boring is good here.

Step 3: Create an API Client Contract​

The UI should not care whether data comes from mock data, SQLite, D1, REST, RPC, or an MCP server.

Create a client interface:

export type MarketplaceClient = {
  listMarketplaceApps(): Promise<MarketplaceApp[]>;
  getMarketplaceApp(slug: string): Promise<MarketplaceApp | null>;
  listDeployments(): Promise<Deployment[]>;
  createCheckout(input: CheckoutInput): Promise<CheckoutSession>;
};

Then provide implementations:

• A mock client for development.
• A fetch client for the real backend.
• Later, maybe an MCP-aware client if the product needs agent workflows.

The UI stays stable while the backend evolves.

Step 4: Convert Screens Into a Feature Package​

Move reusable pages and components into a package:

packages/
  feature-marketplace/
    src/
      MarketplaceRoutes.tsx
      pages/
        MarketplaceBrowsePage.tsx
        MarketplaceAppDetailPage.tsx
      components/
      index.ts

Export the feature surface:

export { MarketplaceRoutes } from "./MarketplaceRoutes";
export { MarketplaceBrowsePage } from "./pages/MarketplaceBrowsePage";
export { MarketplaceAppDetailPage } from "./pages/MarketplaceAppDetailPage";

Remove app-shell ownership from this package:

• No createRoot.
• No top-level BrowserRouter.
• No duplicated auth provider.
• No global CSS reset.
• No hardcoded app-level layout.

The package should be mountable.

Step 5: Mount It in the Host App​

The host app owns the platform.

import { MarketplaceRoutes } from "@your-org/feature-marketplace";

export function AppRoutes() {
  return (
    <Routes>
      <Route path="/dashboard/*" element={<DashboardRoutes />} />
      <Route
        path="/marketplace/*"
        element={
          <ProtectedRoute>
            <MarketplaceRoutes
              basePath="/marketplace"
              client={marketplaceClient}
            />
          </ProtectedRoute>
        }
      />
    </Routes>
  );
}

The feature becomes part of the product, but the host still controls auth, layout, navigation, and route protection.

Step 6: Add a Standalone Shell Only When You Need Independent Deployment​

Sometimes you really do need the marketplace to deploy by itself.

That is valid. Just keep it thin:

apps/
  marketplace/
    src/
      main.tsx
      index.css
      vite.config.ts

The shell should bootstrap the feature:

import { BrowserRouter } from "react-router-dom";
import { createRoot } from "react-dom/client";
import { MarketplaceRoutes } from "@your-org/feature-marketplace";

createRoot(document.getElementById("root")!).render(
  <BrowserRouter>
    <MarketplaceRoutes basePath="" client={marketplaceClient} />
  </BrowserRouter>,
);

Now you have both:

• Embedded marketplace inside the main app.
• Independently deployed marketplace shell.

Without duplicating the product logic.

Step 7: Move Database Assets Only If They Are Truly Shared​

If multiple backends need the same schema or migrations, create a DB package:

packages/
  marketplace-db/
    migrations/
      0001_marketplace_schema.sql

Keep the package focused on schema and migrations. Do not hide backend runtime behavior inside it unless that is clearly part of the contract.

What Not To Do​

Avoid these traps:

• Importing a full standalone app as a dependency.
• Nesting routers inside routers.
• Shipping a second React copy.
• Letting a feature package own the auth provider.
• Letting reusable UI import mock data directly.
• Copying database schemas into multiple apps.
• Upgrading Tailwind inside one package without checking consuming apps.
• Using Module Federation before you actually need runtime composition.

These shortcuts feel fast until the second consumer arrives.

Validation Checklist​

Before calling the integration done, verify:

• The host app builds.
• The standalone shell builds, if it exists.
• The feature works under a route prefix like /marketplace/*.
• The feature works at root in the standalone shell.
• React is a peer dependency in reusable React packages.
• There is only one React instance at runtime.
• The feature does not create its own root router when embedded.
• Global CSS is owned by the app shell.
• Tailwind scans package source files.
• The UI can render from an API client contract, not just mock data.

This checklist catches most integration mistakes before they turn into architecture debt.

FAQ​

Can I integrate one React app into another React app?​

Yes, but the best practice is usually to extract reusable packages from the source app instead of importing the whole app. Put shared types and business rules in a domain package, API calls in an API client package, reusable screens in a feature package, and deployment bootstrapping in thin app shells.

Should I use a monorepo?​

A monorepo is often the simplest option when multiple apps need to consume the same packages. Bun workspaces, npm workspaces, pnpm workspaces, and Turborepo-style setups can all work. The important part is clear package ownership, not the specific workspace tool.

When should I use a micro-frontend?​

Use a micro-frontend when independently deployed apps must be composed at runtime. If you control the repo and can compose packages at build time, a feature package is usually simpler, easier to test, and easier to refactor.

How do I avoid multiple React versions?​

Put react, react-dom, and usually react-router-dom in peerDependencies for reusable React packages. The consuming app should provide those dependencies.

How do I share Tailwind styles across apps and packages?​

Let app shells own global CSS. In Tailwind v4, use @import "tailwindcss"; and add @source entries for package source directories so class names inside packages are included in the build.

What if the original app still needs to deploy independently?​

Keep a standalone shell under apps/your-feature-app. That shell should only handle routing bootstrap, CSS entrypoint, environment setup, and deployment config. The business logic and feature UI should live in packages.

The Creator Takeaway​

The goal is not to make every app reusable.

The goal is to recognize when an app has become a capability.

When that happens, extract the capability:

• Domain package.
• API client package.
• Feature package.
• Optional DB package.
• Thin app shells for each deployment target.

That structure lets you move faster without turning your codebase into a pile of copied screens and hidden assumptions.

I turned this workflow into a reusable agent skill so creators and engineering teams can apply it consistently across projects: App Package Integration.

You can find it on Skills by searching La Rebelion here:

https://skills.sh/?q=la-rebelion In case you are working with AI agents, and MCP servers, here we have more skills that can help you: https://skills.sh/?q=mcp-com-ai

Also, if you want to see a real example of this architecture in action, check out the My Clawster, which is built using this exact pattern integrating the MCP Marketplace into both the main app and a standalone shell.

Use it when you want to integrate one app into another, turn an app into packages, keep an independent app shell, or avoid reaching for micro-frontends too early.

Be HAPI. Go Rebels. ✊🏽

TL;DR: GitHub just launched the MCP Registry, a central hub to discover, trust, and install Model Context Protocol (MCP) servers. This isn’t just a developer convenience—it’s the foundation for how we’ll compose APIs, AI, and agents into workflows. At La Rebelion Labs, we see this as validation of the path we’re already on with the HAPI MCP Stack.

Why this matters now​

Let’s be real:

• APIs are everywhere. Every system has one, but discovery and integration are still messy.

• AI agents need context. Without structured ways to plug into APIs, they hallucinate, break, or fail silently.

• Builders are stuck. Too much time is lost searching for integrations, worrying about trust, and duplicating work.

GitHub’s MCP Registry solves the discovery problem: one place to find vetted MCP servers, right inside VS Code or any MCP-compatible environment.

But the bigger story? This is how API-first architectures evolve into AI-ready ecosystems.

🧩 What is MCP, really?​

• Model Context Protocol (MCP) is a standard that lets AI agents fetch fresh, trusted context from external systems.

• It is the “API for AI Agents”: plug in a new server (like Slack, Jira, Stripe, LinkedIn, Strava, Kubernetes, you name it), and your AI agent instantly knows how to use it.

  We’ve been saying it for months: API-first solutions are the easiest to transform into AI-first. MCP is the bridge.

⚡ GitHub’s big move: The MCP Registry​

Here’s what GitHub shipped:

1. Central Directory – a hub of MCP servers, from partners and the community. Each point links to a GitHub repo, so you can inspect the code and trust what you install.

2. 1-Click Install – With GitHub Copilot in VS Code, you can add MCP servers without digging through documentation or repositories. (I am more in favor of remote servers, but we still have plenty implemented with stdio transport 🤷🏽‍♂️).

3. Trust Signals – ranking and metadata (stars, activity, provenance) help filter noise.

4. Open Ecosystem – anyone can publish to the OSS MCP Community Registry, which then syncs into GitHub’s directory.

This can be translated into spending less time searching, reducing the risk of guessing, and increasing building speed.

💡 Why this aligns with La Rebelion Labs’ vision​

At La Rebelion Labs, we’ve been building the HAPI MCP Stack—a framework where APIs and AI meet:

• HAPI Server → headless API instances that expose REST + MCP endpoints.

• OrcA → an orchestrator to visually design Arazzo-compliant workflows in VS Code.

• QBot & runMCP → tools to simplify how developers test and consume MCP servers.

  • RunMCP is, by itself, an MCP registry. 🤓

The MCP Registry? It’s the missing puzzle piece that confirms this movement. GitHub just made it mainstream.

When you put GitHub’s registry + HAPI Stack together, you get a whole supply chain for AI integrations:

• Discover → find servers in the Registry.

• Deploy → run them via HAPI Server.

• Compose → orchestrate with OrcA.

• Consume → connect through RESTful or MCP Clients!

This isn’t theory. It’s already working in our stack.

🏢 Business Translation: What leaders should care about​

• Faster time-to-market with safer, standardized AI integrations. The risk of “shadow AI tools” decreases when discovery and trust are centralized.

• Accelerate feature delivery. Instead of writing custom integrations, pick from the MCP servers, or transform Swagger into MCPs. Example: Connect your roadmap tool (e.g., Jira, Linear) to AI workflows in days, not quarters.

• Better UX with AI copilots that actually know your stack. Fewer broken prompts, more consistent results.

• Stop reinventing integrations. Utilize trusted MCP servers and focus your energy on addressing unique problems.

🌍 Ecosystem impact​

This shift is bigger than GitHub:

• Standardization: Just like OCI standardized containers, MCP + registries will standardize AI toolchains.

• Open Collaboration: The OSS MCP Community Registry ensures anyone—startups, enterprises, hobbyists—can contribute.

• Trust Layer: Verified metadata and provenance become the guardrails for enterprise adoption.

The registry is the App Store moment for MCP servers.

🔮 What’s next​

We’re still early. Expect:

• Self-publishing flows: easier ways to push MCP servers into the registry.

• Metadata maturity: verification, usage metrics, security scans.

• Enterprise overlays: private registries for regulated environments.

• Composable AI stacks: where registries, orchestrators, and agents form complete ecosystems.

La Rebelion Labs is already exploring airgap registries, extended SBOMs for MCP servers, and multi-cloud distribution—bridging GitHub’s registry to zero-trust and enterprise needs.

✅ What to do now​

• Developers: Explore the MCP Registry and try installing a server that matches your workflow (e.g., GitHub Issues, Slack, Kubernetes)… or spin up an MCP Server from your Swagger.

• Product Leaders: Audit your roadmap. Where could MCP servers accelerate delivery?

• Security Teams: Define Your Internal MCP Trust Policy. What’s approved? What’s blocked?

• Innovators: Think beyond tools. How will MCP reshape your business model?

🚀 Bottom line​

GitHub’s MCP Registry is more than a directory. It’s a signal: the future of API + AI is composable, discoverable, and trusted.

At La Rebelion Labs, we’re building alongside this wave with the HAPI MCP Stack.

👉 If you want to survive (and thrive) in the new agentic era, start with MCP servers. The registry is your gateway.

Go Rebels! ✊🏽

That world is here.

OpenAI's allowing to connect Model Context Protocol (MCP) has just crossed a huge milestone: ChatGPT can now connect with "custom" MCP Servers. And with HAPI MCP Servers, you can start building and connecting your own today in seconds.

But there's a caveat: right now, ChatGPT only works if your MCP Server implements two specific tools: search and fetch. Don't worry—I'll guide you through setting it up, explain what it means, and show you why this makes a significant difference.

What Is MCP, and Why Should You Care?​

Let's break it down.

• APIs today: Think of APIs as doors. If you have the right key (credentials, documentation, SDK), you can open them. But every door looks different. Some are REST, some GraphQL, some gRPC. Some are well-documented, others are a nightmare.

• MCP's promise: MCP standardizes how AI models like ChatGPT talk to APIs. Instead of building one-off integrations, you build a server that follows the MCP spec. Once that's done, ChatGPT automatically knows how to talk to it. (or any other MCP-compatible client, i.e. Claude Desktop, QBot).

• The business angle: This isn't just technical elegance—it's faster integrations, less developer overhead, and reduced cost of maintaining custom connectors. That means faster time to market and lower risk.

In short: MCP turns APIs into AI-ready services.

⚡ The Big News: ChatGPT Meets Custom MCPs​

Until now, ChatGPT has only worked with a fixed set of tools. Think of them as pre-installed apps. Useful, but limiting.

Now? You can bring your own MCP Server into ChatGPT. That's like installing your own app in the App Store of AI.

With HAPI MCP Servers, the door is open:

• You define your MCP logic (Swagger/OpenAPI, custom code, etc).

• You expose it through the MCP standard (one command line to start).

• ChatGPT connects and can be immediately used.

But there's a catch…

⚠️ The Caveat: search and fetch​

Here's the current limitation (at least as of when this was written): ChatGPT will only talk to custom MCP Servers that expose two specific tools:

1. search – Let’s ChatGPT ask your server what resources are available.

   • Think of it like browsing an API catalog.

   • Example: ChatGPT can "search" for available endpoints, functions, or datasets.

2. fetch – Let’s ChatGPT request a resource by name.

   • Think of it like hitting "download" on the resource you found.

   • Example: ChatGPT can "fetch" a specific record, report, or file.

👉 Without these two, ChatGPT won't know how to interact with your MCP Server, and as of now, it won't work at all, even if your MCP server exposes other tools. You will get an error: “This MCP server doesn’t implement our specification. “

This is important. It means that if you're building your own MCP, you need to start with search and fetch as your baseline tools, at least for now, if you want ChatGPT to connect.

🛠️ Step 1: Build Your First MCP with HAPI​

Here's where it gets exciting.

With HAPI MCP Servers, you don't have to reinvent the wheel. HAPI gives you a framework to:

• Take your API logic.

• Wrap it in MCP's protocol.

• Expose it so ChatGPT can connect.

Think of HAPI as a Gateway for MCP Servers—a lightweight, flexible way to spin up a server that speaks MCP fluently.

🧩 Step 2: Point HAPI to your OpenAPI/Swagger (auto-generates search)​

With HAPI MCP Servers, you don't implement search. HAPI reads your OpenAPI/Swagger spec and auto-builds the resource catalog, exposing a standards-compliant search tool automatically.

What to do:

• Provide your OpenAPI/Swagger spec (file or URL).

• Start HAPI MCP against that spec.

Example (pay attention to the --chatgpt flag):

# Local file
hapi serve petstore --headless --chatgpt

# Or remote spec
hapi serve --openapi https://petstore3.swagger.io/api/v3/openapi.json

Result:

• search is available immediately, listing operations/resources derived from your spec (endpoints, tags, summaries, etc.).

• No custom code required.

🧩 Step 3: Zero‑code fetch (auto-generated)​

You also don't implement fetch. HAPI maps each searchable resource to a concrete retrieval operation using your OpenAPI details (paths, params, auth, and response schemas).

What you get:

• fetch executes the proper request and returns JSON/text per the spec.

• Response shaping and content-type handling come out of the box.

Optional:

• You can override defaults (e.g., auth, headers, timeouts), but it's not required for ChatGPT connectivity.

🔌 Step 4: Connect It to ChatGPT​

OpenAI's MCP docs show how to connect MCP Servers. Here's the gist:

1. Run your HAPI MCP Server locally or in the cloud.

   1. If you run it locally, use a tool like ngrok to expose it publicly.

   2. If you want to run it in the cloud, install it on any VM server or use runMCP.

2. Go to your ChatGPT settings → Connectors → Create.

3. Fire up ChatGPT and test!

From that point on, ChatGPT treats your MCP like a first-class citizen. Ask it:

"What's in my Q1 Revenue Report?"

And instead of hallucinating, ChatGPT fetches real data from your MCP. Is RAG from your own systems!

Demo Time!​

Here's a quick demo of how it works in practice:

🎯 Business Impact: Why This Matters​

Let's translate the tech into business value.

• For executives: This reduces integration costs and speeds up AI adoption.

• For PMs: You can now think of MCPs as product features. Want ChatGPT to "understand your platform"? Wrap your API in MCP and ship it.

• For engineers: It's one spec to learn. One server to implement. No more writing custom ChatGPT plugins.

• For designers & end-users: It means faster, smoother, and more reliable AI-powered workflows. Less "Sorry, I don't know that" and more real answers from real systems.

📚 A Guided Path: From Zero to MCP​

Here's how you can get started:

1. Read the MCP spec – OpenAI's MCP docs.

2. Use HAPI – the quickest way to spin up your MCP Server.

3. Start small – customize search and fetch. Test them with ChatGPT.

4. Iterate – add more tools once the basics work.

And remember: these are early days. My expectations are high. The current limitation (only search + fetch) will expand. Soon, you'll be able to expose more advanced tools and workflows. 🤞🏽

What's Next?​

Here's where I see this going:

• Beyond search and fetch – Future versions of ChatGPT will support richer tools. Imagine create, update, delete, or even full workflow orchestration.

• Enterprise MCPs – Companies will wrap entire business systems in MCP to make them AI-ready.

• Agent-to-Agent Communication – MCP makes it possible for different AI agents (not just ChatGPT) to talk to the same backend services consistently.

This isn't just a developer milestone—it's a paradigm shift for AI-powered business workflows.

✅ Final Thoughts​

The integration of ChatGPT with custom MCP Servers is one of those rare shifts that unlocks a cascade of possibilities.

Today, it's simple: implement search and fetch. Tomorrow, it's expansive: AI systems deeply integrated with your data, tools, and workflows.

With HAPI MCP Servers, you don't just consume this future—you build it.

So, the question isn't "Should I try this?" It's: How fast can you wrap your API in MCP and let ChatGPT talk to it?

🔗 Resources

• OpenAI MCP Documentation

• HAPI MCP Servers