Cursor vs Fabriq: Why Agent-Agnostic Architecture Wins

TL;DR. The AI coding tool market is fragmenting rapidly — new agents, new backends, new protocols every quarter. Tools that hardcode a single agent become obsolete as the landscape shifts. Fabriq's approach is agent-agnostic: it defines a protocol (ACP — Agent Communication Protocol) and works with any agent backend that speaks it — OpenCode, Claude Code, or custom implementations. This post explains why protocol-level thinking beats vendor-lock thinking, and how the ACP design makes Fabriq future-proof as the agent ecosystem evolves.

The integration tax#

Every AI coding tool today integrates with one agent. Cursor has its own agent mode. GitHub Copilot has Copilot Chat. Continue.dev has its agent system. Each integration is bespoke, each has a different API, and each requires ongoing maintenance as the upstream agent evolves.

The integration tax shows up in three ways:

1. Implementation cost. Every new agent integration requires rebuilding the same plumbing — session management, tool call routing, permission enforcement, event handling.
2. Maintenance cost. Agent backends update their APIs. Each update breaks the integration. The tool maintainer plays catch-up.
3. Migration cost. If a better agent emerges, switching requires rewriting the integration layer. Teams stay on inferior agents because the switching cost is too high.

The protocol approach#

Fabriq avoids the integration tax by defining a protocol rather than building a plugin.

The Agent Communication Protocol (ACP) is a stdio-based JSON-RPC protocol that defines:

• Session lifecycle — attach, detach, session health
• Tool discovery — what capabilities does this agent expose?
• Tool execution — invoke a tool with typed input, receive typed output
• Permission requests — agent requests permission for a sensitive operation; the host approves or denies
• Events — streaming progress, status changes, error propagation

Any agent backend that implements the ACP contract can work with Fabriq. Today, that means:

• OpenCode — primary development target, full ACP implementation
• Claude Code — supported via ACP bridge
• Custom agents — anything that speaks stdio JSON-RPC with the APC schema

// The ACP contract is simple by design:
interface ACPBackend {
  createSession(params: SessionParams): Promise<Session>;
  executeTool(sessionId: string, toolCall: ToolCall): Promise<ToolResult>;
  requestPermission(sessionId: string, request: PermissionRequest): Promise<PermissionResponse>;
  destroySession(sessionId: string): Promise<void>;
}

How this changes the game#

For the tool (Fabriq)#

Fabriq's agent integration is one implementation — the ACP host — that works with any compliant backend. Adding a new agent backend means implementing the ACP interface, not rebuilding the entire integration layer.

When a new hot agent launches next quarter, Fabriq can support it by implementing one TypeScript interface. Weeks, not months.

For the team#

The team is not locked into a single agent vendor. They can:

• Default to OpenCode for daily development
• Switch to Claude Code for tasks where Claude's reasoning is superior
• Experiment with new agents without changing their workflow
• Run a local model (via Ollama's ACP-compatible wrapper) for sensitive code

The workspace is independent of the agent. The agent is a backend — swappable, upgradeable, replaceable.

For the agent ecosystem#

A standard protocol lowers the barrier to entry for new agent backends. Instead of needing to build integrations with every tool, a new agent just implements ACP. The protocol becomes the thin waist of the ecosystem.

The comparison: Cursor vs. Fabriq#

This table captures the architectural difference:

This isn't a criticism of Cursor's quality — Cursor's agent is excellent. It's a statement about architecture. An agent-agnostic design is a bet on ecosystem evolution: the best agent in 2027 may not be the best agent in 2026. A tool that can adapt without rewrites has a structural advantage.

How ACP works in practice#

When Fabriq connects to an agent backend, the flow is:

// 1. Fabriq starts the agent process (e.g., `opencode agent`)
const agentProcess = spawn("opencode", ["agent", "--acp"]);
 
// 2. Fabriq creates an ACP session
const session = await acpHost.createSession(agentProcess, {
  workspaceRoot: "/path/to/workspace",
  features: ["cdr", "validation", "knowledge"],
});
 
// 3. The agent discovers available tools
const tools = await session.discoverTools();
// Returns: [{ name: "read_file", schema: ... }, { name: "edit_file", schema: ... }, ...]
 
// 4. Fabriq invokes tools on behalf of the feature workbench
const result = await session.executeTool("edit_file", {
  path: "features/order-search/src/service.ts",
  content: newCode,
});
 
// 5. Agent requests permission for sensitive operations
session.on("permissionRequest", (request) => {
  // Fabriq surfaces this in the workbench UI
  // Human reviews and approves/rejects
  return humanDecision;
});

The agent is a process, not an integration. It runs locally, communicates over stdio, and follows a typed contract. Fabriq doesn't care what model the agent uses internally — it cares about the protocol.

The future of agent protocols#

ACP is not a formal standard (yet). It's a practical protocol that evolved from Fabriq's requirements. But the industry is moving in this direction:

• Anthropic's Model Context Protocol (MCP) standardizes tool definitions for LLMs
• The Agent Communication Protocol emerging from the agent interoperability community
• Fabriq's ACP bridges the gap between the agent process and the workspace shell

We believe the long-term winner will be protocol-based agent integration, not proprietary agent lock-in. Fabriq's architecture is a bet on that future — and it's available today.

Fabriq's ACP implementation is open source on GitHub. Download Fabriq and bring your own agent, or read the agent spec.