There are many factories, but this one is yours
There are two concepts you need to know: workflows (what's run, plain TypeScript functions) and adapters (a workflow's bridge to one outside thing: git, GitHub, Slack, an agent, you). The full model lives in the engine docs.
With these two things you can build incredibly complex workflows, including, but not limited to, software factories.
Let me tell you. Because.
Every coding harness and code factory has the same flaws:
Why should the guys at Vercel, Linear, Factory, Anthropic, or OpenAI decide what workflow is best for you?
Penguin flips that. You decide.
Is the agent done, or is it waiting on you? With most tools you find out by scrolling.
In Penguin the distinction is built in. An agent turn ends in a typed result you define. A workflow can pause on a question (view.ask("Ship it?")) and does not move until you answer. When nothing needs you, it keeps moving on its own.
If you want a workflow that runs another workflow that runs several agents, all in parallel, prose falls apart fast. Code doesn't. Loops, retries, conditions, composition: TypeScript already does all of that, so that's what workflows are written in.
When you implement a GitHub issue or a Jira ticket, or review a PR, you are ALWAYS going to pull the info from those sources first. That's a deterministic call, not a job for an agent poking at an MCP. Adapters make it one function call.
You can build a workflow with steps and blockers without ever calling an agent.
Workflows can respond to anything you can build an adapter for: Slack, GitHub, Jira, a webhook, you.
Still early beta, but I'm already using Penguin at work, and to build Penguin.
Apache License 2.0. See LICENSE.
266 commits
6 commits
TypeScript
91.7%
Rust
6.6%
CSS
1.1%
There are many factories, but this one is yours
There are two concepts you need to know: workflows (what's run, plain TypeScript functions) and adapters (a workflow's bridge to one outside thing: git, GitHub, Slack, an agent, you). The full model lives in the engine docs.
With these two things you can build incredibly complex workflows, including, but not limited to, software factories.
Let me tell you. Because.
Every coding harness and code factory has the same flaws:
Why should the guys at Vercel, Linear, Factory, Anthropic, or OpenAI decide what workflow is best for you?
Penguin flips that. You decide.
Is the agent done, or is it waiting on you? With most tools you find out by scrolling.
In Penguin the distinction is built in. An agent turn ends in a typed result you define. A workflow can pause on a question (view.ask("Ship it?")) and does not move until you answer. When nothing needs you, it keeps moving on its own.
If you want a workflow that runs another workflow that runs several agents, all in parallel, prose falls apart fast. Code doesn't. Loops, retries, conditions, composition: TypeScript already does all of that, so that's what workflows are written in.
When you implement a GitHub issue or a Jira ticket, or review a PR, you are ALWAYS going to pull the info from those sources first. That's a deterministic call, not a job for an agent poking at an MCP. Adapters make it one function call.
You can build a workflow with steps and blockers without ever calling an agent.
Workflows can respond to anything you can build an adapter for: Slack, GitHub, Jira, a webhook, you.
Still early beta, but I'm already using Penguin at work, and to build Penguin.
Apache License 2.0. See LICENSE.
266 commits
6 commits
TypeScript
91.7%
Rust
6.6%
CSS
1.1%