Forge evolves: from SDLC pipeline to workflow engine for AI agent teams

When we first announced Forge a few weeks ago, the headline was “from GitHub issue to PR, with a five-agent AI pipeline.” Today we’re broadening that headline: the same engine now runs any team you can describe in plain English — researchers, marketers, analysts, support agents, developers, or any mix.

The 5-role SDLC pipeline isn’t going anywhere. It’s still our most polished preset, and it’s still where we have eighteen months of depth. What changed is that the underlying engine is now exposed: you can take the same architecture — personas with transitions, a management agent validating every handoff, git as the audit trail — and point it at any workflow your team would otherwise hire a contractor or stitch together SaaS tools to handle.

The brief that broke our framing

A few weeks ago a customer wrote us a brief that didn’t fit the SDLC mold:

“I need Alex as PM to set requirements, Sam to do the research, Jordan to analyze the results, Riley to write the blog post. Alex controls all transitions and validates each handoff.”

That’s a content workflow, not a software-delivery workflow. The roles are different, the output is a blog post (not a pull request), and three of the four personas aren’t engineers at all. But the architecture — multiple specialized personas, sequential handoffs, a designated manager checking each transition — is identical to our SDLC pipeline.

So we generalized it. The engine you’ll see described as “the Forge workflow engine” today is the same code path that ships your reviewed pull request. The only thing that changes between a content workflow and an SDLC workflow is the spec.

How it works

You write the brief. Forge generates a workflow spec. You approve. Forge runs it:

flowchart TD
    B([Brief in plain English]) --> G[NL generator]
    G --> S{{Workflow spec}}
    S --> A{Operator approves?}
    A -->|Yes| R[Run]
    A -->|Edit| S
    R --> P1[Persona 1]
    P1 --> M1{Manager verdict}
    M1 -->|advance| P2[Persona 2]
    M1 -->|enrich| P1
    P2 --> M2{Manager verdict}
    M2 -->|advance| Pn[...]
    Pn --> O([Output committed to git])

Three pieces matter:

1. The natural-language generator parses your brief (any language) into a WorkflowSpec of named personas + transitions + a designated management agent. You see the draft, edit anything that’s off, then approve.
2. The management agent sits between every transition. It reads the previous persona’s handoff and decides: advance to the next persona, enrich (loop the previous persona back with specific instructions), or escalate to a human. No bad output flows downstream; no operator has to babysit each step.
3. Git is the audit trail. Every persona’s handoff is a commit on a workflow-scoped branch — your repo if you link one, our hidden shared repo if you don’t. You can git diff between enrich attempts. Compliance auditors get git log and they’re done.

What made this possible now

The engine isn’t a from-scratch rewrite. Three substrates that shipped over the last few weeks made it composable:

• Custom roles registry (Pattern B) — operators were already defining their own role identifiers and chaining them via Role.DownstreamRole. The workflow engine just consumes that registry instead of a hardcoded [PM, Architect, Developer, QA, Reviewer] list.
• Runtime registry + capability matching — each persona declares what it needs (heavy code-execution? lightweight reasoning?), and our matcher picks the cheapest runtime that fits. A research persona costs a fraction of what a developer persona costs to run; the engine knows the difference.
• Review-fix rounds (the prototype of the management-agent pattern) — bounded reviewer→developer loops with verdict markers. We generalized the pattern: any character can be the management agent for any transition.

Once those three were in place, the workflow engine fell out as the natural next composition.

SDLC is still our depth

We want to be explicit about what’s not changing:

• The 5-role SDLC pipeline ships exactly the same way it always has. Label a GitHub issue with forge-pipeline, get a reviewed PR. No customer using the SDLC preset needs to do anything different.
• Our deepest expertise is still software delivery — the LLMOS deterministic runtime, the GitHub App integration, the typed handoff schemas, the character agents with persistent memory . All of that gets stronger as we invest in the SDLC preset specifically.
• We benchmark against Claude Code, Cursor, Replit’s agent, Factory.ai — the generic agentic tooling category. The SDLC preset is our marquee comparison there.

What’s different: we’re no longer only competing on SDLC. The same product now serves teams that don’t have a single line of code in their workflow.

What this opens up

For our existing customers, nothing changes in the short term. The SDLC pipeline runs the same way.

For prospects we couldn’t serve before — a marketing agency, a research firm, a 30-person consultancy with internal-ops workflows — the conversation just got simpler. “Describe your team in English; Forge runs it” is a sentence anyone can repeat to their CFO.

For Russian and other non-English-speaking customers especially: the NL generator is multilingual by default. Russian briefs, Spanish briefs, Mandarin briefs — same engine, same git audit trail.

Try it

If you’re already using the SDLC pipeline, nothing changes — your workflow keeps running.

For a new workflow, the flow is short:

1. Open “New Workflow” in your Forge dashboard.
2. Describe what you want, in plain English. “I need someone to research the topic, an analyst to summarize the findings, and a writer to draft a blog post. A PM should check each handoff before the next person starts.”
3. Hit “Generate Workflow.” Forge maps the personas in your brief to characters from your existing roster. For any role you don’t have a character for yet, Forge offers to generate one on the spot — tuned to the role hint, your past workflows, and the brief. Review the auto-drafted persona, tweak if you like, accept.
4. Review the visual flowchart: characters as avatar cards, transitions as arrows, the management agent highlighted. Click any node to edit, drag to reorder, swap a character with one click.
5. Run now to execute immediately, or Schedule to run on a cron — every Monday morning, end of each sprint, when a webhook fires. Forge handles the rest.

No JSON, no terminal, no scripting. The workflow API exists for integrations and CI scripts; the consumer-facing path is just describe, generate, run.

If you have a workflow shape that doesn’t fit SDLC and you’d like to think through how Forge would run it, reach out at [email protected] . Read the deeper Workflow Engine and Git-Backed Audit pages for what’s under the hood.

The engine is shipped. The SDLC preset is shipped. Marquee non-SDLC presets — content workflows, research workflows, ops workflows — are templates we’ll publish over the coming weeks.

We’re not pivoting. We’re widening the lens on the same engine.