Fabric: Treating AI Prompts as Infrastructure Instead of Conversations

Hook

While most developers treat AI prompts like throwaway Slack messages, Fabric treats them like infrastructure-as-code—version-controlled, shareable, and systematically organized across 15+ AI providers.

Context

The AI integration problem isn't about access anymore—it's about chaos. Most developers have ChatGPT, Claude, and Gemini tabs perpetually open, copy-pasting the same prompts daily, tweaking them slightly each time, and losing the good versions forever. Teams duplicate effort because there's no systematic way to share what works. You've perfected a prompt for summarizing pull requests or extracting action items from meeting notes, but it lives in your browser history, not your toolchain.

This fragmentation gets worse as AI providers multiply. OpenAI's API has different authentication than Anthropic's. Azure's enterprise features don't talk to Google's. You end up with scattered scripts, hardcoded API keys, and no consistent interface. Fabric emerged from this frustration: what if prompts were treated as first-class artifacts—stored in files, version-controlled in git, organized by purpose, and executable against any AI provider through a single CLI? What if your best prompts could be as shareable and reproducible as your Terraform modules or Kubernetes manifests?

Technical Insight

Fabric's architecture centers on 'patterns'—individual prompt templates stored as plain text files in a structured directory hierarchy. When you run fabric --setup, it creates ~/.config/fabric/patterns/, which becomes your local pattern library. Each pattern is simply a markdown file containing the system prompt. Want to summarize content? Run cat article.txt | fabric --pattern summarize. The pattern file gets loaded, your input gets injected, and the result streams back.

Here's what a basic pattern looks like:

# system
You are an expert at extracting actionable insights from technical documentation.

Analyze the input text and output:
- Key technical decisions and their rationale
- Potential risks or trade-offs mentioned
- Action items or next steps

Format as structured markdown with clear headings.

# user
{{ .Input }}

The power emerges when you chain patterns with Unix pipes. You can pull a GitHub issue, extract action items, then send those to another pattern for prioritization: gh issue view 123 | fabric --pattern extract_actions | fabric --pattern prioritize_tasks. This composability transforms AI from a chat interface into a pipeline component.

The vendor abstraction layer is where Fabric's Go implementation shines. Instead of learning each provider's SDK, you configure credentials once and switch models with a flag. The configuration lives in ~/.config/fabric/.env:

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=AIza...
DEFAULT_MODEL=gpt-4

Now running fabric --pattern analyze_code --model claude-opus-4 uses Anthropic's Claude, while --model gemini-pro switches to Google—same pattern, different backend. The Go codebase maintains provider-specific clients that implement a common interface, handling authentication, rate limiting, and streaming responses uniformly. This abstraction extends to enterprise providers: Azure Entra ID integration means corporate SSO works seamlessly, and GitHub Models support lets you experiment with cutting-edge models without separate API keys.

The pattern repository itself acts like a package manager for prompts. Running fabric --update-patterns pulls the latest community patterns from GitHub, similar to brew update. The official repository includes 100+ patterns organized by category: /summarize for condensing content, /extract_wisdom for pulling insights from podcasts, /create_quiz for educational content, /analyze_security for code review. Each pattern is a collaborative artifact—you can fork patterns, customize them for your needs, and submit improvements back upstream.

Fabric's REST API mode (fabric --serve) exposes these patterns as HTTP endpoints, enabling integration with non-CLI tools. A simple POST request executes any pattern:

curl -X POST http://localhost:8080/api/pattern/summarize \
  -H "Content-Type: application/json" \
  -d '{"input": "Long article text...", "model": "gpt-4"}'

This architecture choice makes Fabric extensible beyond terminal use—browser extensions, Slack bots, or CI/CD pipelines can leverage the same pattern library. One team uses it in GitHub Actions to automatically analyze PR descriptions and suggest reviewers based on the code areas touched. Another built a Slack bot where /fabric summarize <url> pulls and condenses linked articles.

The internationalization layer deserves attention too. Fabric doesn't just translate UI strings—it maintains locale-aware pattern directories. When you set FABRIC_LANGUAGE=es, patterns in /patterns/es/ take precedence, allowing culturally-appropriate prompt engineering. A Japanese summarization pattern might emphasize different structural elements than an English one, respecting linguistic conventions beyond simple translation.

Gotcha

Fabric is an orchestration layer, not an AI service. Every pattern execution hits a paid API—OpenAI, Anthropic, Google, whoever you've configured. If you're running fabric --pattern summarize on 50 documents daily, you're paying for 50 API calls at your provider's rates. There's no caching layer by default, no local model support, and no 'free tier' beyond what your AI provider offers. For heavy usage, costs add up quickly, and you need to implement your own rate limiting or caching strategies.

Pattern quality varies wildly because the repository is crowdsourced. Some patterns are meticulously crafted with specific output formats and edge case handling. Others are barely-tested prompts someone threw together. There's no systematic quality review, versioning for individual patterns, or deprecation strategy. A pattern that worked brilliantly six months ago might produce mediocre results with newer models that have different training or instruction-following characteristics. You'll need to audit patterns before relying on them in production workflows, and potentially maintain your own fork with curated, tested versions.

The CLI-first design is both strength and limitation. If your team includes non-technical users who need AI augmentation, Fabric's terminal interface is a non-starter. The REST API helps, but you're building custom interfaces from scratch. Tools like LibreChat or ChatGPT's web UI offer ready-made collaboration features—conversation sharing, team workspaces, usage analytics—that Fabric doesn't address. It's a power tool for developers, not a platform for organization-wide AI deployment.

Verdict

Use if: You're a developer who runs repetitive AI tasks (summarizing docs, analyzing logs, extracting structured data) and want reproducible, version-controlled prompts. Use if you need vendor flexibility—switching between OpenAI, Anthropic, and Google based on model capabilities or pricing. Use if you value composability and want AI as a Unix pipeline component alongside grep, jq, and sed. Use if you're building automation where AI is one step in a larger workflow (CI/CD, data processing, content generation pipelines). Skip if: You need a conversational AI interface with history, context management, and collaborative features—direct provider UIs or LibreChat are better fits. Skip if you want cost-effective heavy usage—without local model support, API costs will exceed alternatives. Skip if your team isn't comfortable with CLI tools or you need to democratize AI access to non-technical users. Skip if you require fully air-gapped, self-hosted AI without external dependencies—Fabric always calls external APIs.