Who Forge is for

If you write runbooks today — operational procedures, incident response steps, security playbooks, audit procedures, support escalation paths, customer onboarding sequences — you can write Forge skills. The format is the same prose you already write, with a frontmatter block on top declaring what tools and integrations the skill needs.

Concretely: an SRE who has documented their pod-restart triage process can turn that documentation into a working agent by adding frontmatter declaring access to kubectl and a few environment variables. A security engineer who maintains a vulnerability-triage playbook can convert it into a skill that the LLM follows step-by-step. A compliance officer who maintains a quarterly access-review procedure can codify it as a skill that runs on a schedule and produces the evidence artifact the audit needs.

The Skill Builder UI — opened with forge ui and served locally with no external dependency — is designed for this audience. It gives a structured editor for the frontmatter, a markdown editor for the body, and immediate preview of how the agent will execute. No Python, no framework, no deployment manifest.

What domain experts get from Forge:

• The agent is a document they can author and review without writing code.
• The same skill that lives in their team's Confluence or runbook repository can be made executable without rewriting.
• Skills are versioned in git, reviewed in pull requests, and signed for production use — the same workflow operational documents already follow at most organizations.
• Domain experts can iterate on a skill without involving an engineer for every change, the way they iterate on documentation today.

Many skills need more than what an LLM can do alone. They need to call APIs, query databases, run kubectl commands, parse complex outputs, or perform deterministic actions where LLM judgment is unsafe. That's where developers come in.

Forge skills can include scripts in their scripts/ directory — Bash, Python, Go, anything. The frontmatter declares which scripts the skill exposes as tools. The LLM, reading the skill body, sees the tools as named functions it can invoke. A developer writes the script once; the domain expert who owns the skill body uses it as a tool the way an LLM uses any other tool.

The collaboration shape: a domain expert writes the skill body in markdown, naming the tools they'd like the agent to have. A developer reads the skill, writes the scripts for the tools the domain expert specified, declares them in frontmatter. The domain expert iterates on the body without touching scripts. The developer iterates on scripts without touching the body. Both versions live in the same SKILL.md directory and are reviewed together.

What developers get from Forge:

• A clear contract between domain logic (markdown body) and tool implementation (scripts in any language).
• A runtime that handles LLM invocation, tool dispatch, egress enforcement, and audit logging — so developers focus on the tool, not the agent infrastructure.
• The same multi-language tool support across every Forge deployment — develop locally with forge run, ship with forge package, deploy with the standard Kubernetes manifest.

Once skills exist, they need to run somewhere production-grade. Platform engineers, SREs (in their operator capacity), and DevOps teams are the audience for Forge's runtime layer — the single static binary, the Kubernetes deployment patterns, the egress enforcement model, the audit logging, the autowire trust pipeline.

This audience cares about: how does the runtime fit alongside the services we already operate? What's its resource footprint? How does it observe through our existing Prometheus and Grafana? How does it authenticate with the IdP we already use? Can we run it air-gapped? Can it survive a node failure? Can the security team review it end-to-end?

Forge is designed to make those questions cleanly answerable. The runtime is a Go binary, no daemon, no DinD, no managed-service dependency. It deploys with standard Kubernetes manifests. It enforces egress at the runtime layer with per-skill allowlists. It emits structured audit logs with correlation IDs. It supports local model inference for air-gapped deployment. It can be embedded in another service as a library when that fits the architecture better.

What platform engineers get from Forge:

• A single static binary they can deploy with whatever orchestration they already use.
• A runtime security model that doesn't depend on the underlying cloud — same egress controls and audit posture on EKS, AKS, GKE, or on-prem.
• Zero managed-service dependency, zero phone-home, no vendor billing surface beyond model APIs.
• Standard observability via OpenTelemetry — flows into the SIEM and metrics platform already operating.

The SKILL.md format is the contract. Domain experts write the body. Developers write the scripts. Platform engineers operate the runtime. The same document is the source of truth for all three roles.

A working example: an enterprise SRE team wants an agent that triages Kubernetes incidents. The senior SRE who knows the team's actual triage process writes the skill body in markdown — the diagnostic steps, the safety constraints, the escalation rules. The platform team's developer writes scripts for the kubectl invocations and the Slack notifications. The platform engineer deploys the skill as a Kubernetes sidecar to the cluster being monitored, with audit logs flowing into Splunk and egress restricted to the cluster's internal API only.

Every change to the agent's behavior — refining the triage process, adding a new escalation rule, tightening the egress allowlist — happens through pull requests against the SKILL.md repository. The domain expert reviews body changes. The developer reviews script changes. The platform engineer reviews frontmatter and deployment changes. The agent improves like any other operational document, with the right people reviewing the parts they own.

That's the difference between an agent as code and an agent as document. Code excludes everyone who doesn't write code. Documents include everyone who can read them, and the contract between roles is visible to all of them.

Forge is not designed for the "I want an agent to help with my email and my calendar on my Mac" use case. That's a desktop assistant, and Claude Cowork is the right product for it. Cowork runs on your laptop, talks to the SaaS apps you personally use, completes tasks on your behalf, and shuts down when you don't need it.

Forge is designed for the agent that runs as a service — for your team, your organization, your customers. The author of that agent might not be a developer (and often isn't — the best people to author production runbook-style agents are the SREs, security engineers, and operations leads who own the underlying processes). But the agent itself lives in your infrastructure, runs continuously or on schedule, and serves a function that goes beyond one person's productivity.

The distinction is the deployment shape and audience of the agent, not the technical sophistication of the author:

• A non-developer building an agent for themselves, on their machine → Claude Cowork
• A non-developer building an agent for their organization, running as a service → Forge