Ways to automate engineering work
Compare how local coding agents, agent automations, CI platforms, and Shipfox run and coordinate engineering work.
What sets Shipfox apart
Control at every step
You decide what each agent can use, which checks must pass, and who approves.
You write each workflow as code in your repository, so your whole team uses the same process. For each step, you choose which tools the agent can use and which checks must pass. You choose where a person must approve. Each agent gets only the access it needs, never a personal account. Nothing merges without your approval.
Any model, no lock-in
Choose the best model, and its cost, for each step. You are not tied to one provider.
You choose a model for each step. Use a low-cost model for simple work, and a stronger model only when you need it. You see the cost of each run, and you can set a limit. Shipfox is open source, so you can host it yourself and move your workflows to another system at any time.
More than a prompt
Loops, waits, and agents mixed with the commands you choose.
A simple tool runs one prompt and then stops. Most work needs more. A Shipfox workflow has many steps. It can repeat a step until your checks pass. It can also wait for an event, such as a review comment or a failed check. Then it starts the agent again with all the earlier context. You can also mix agent steps with normal commands, which are fast and give the same result every time.
100+ integrations
Start a workflow from your tools, and let agents use them.
A workflow can start from many sources: a ticket, an alert, a chat message, a failed check, or a schedule. During the workflow, agents can read and write in your other tools, and you give this access one step at a time. Shipfox is not limited to where you store your code. You can connect a new tool in a few minutes.
Detailed comparison
Swipe to compare.
| Comparison point | Local coding agent | Agent automations | CI platform | Shipfox |
|---|---|---|---|---|
| Example providers | ||||
| Products | ||||
| Running work | ||||
| Where code runs | Engineer's machine | Provider-managed cloud runner | Hosted or self-hosted runners | |
| Execution environment | No runner choice | Preset runner environment | Custom runners, images, and network | |
| Parallel work | No managed parallel jobs | Parallel managed runs | Parallel jobs within runner capacity | Parallel jobs by default |
| Triggers | Human starts a session | Provider-supported events and schedules | Repository events, schedules, and webhooks | |
| Coordinating agents and steps | ||||
| Later review comments | Engineer follows up in chat | New automation run | New workflow run | |
| Failed check needs a code fix | Engineer prompts another attempt | No independent feedback gate | Checks fail jobs; no built-in agent repair | |
| Agent and fixed steps in one flow | No workflow orchestration | No built-in mixed-step workflow | Agent call needs job scripting | |
| Agent conversation across steps | No shared workflow session | No cross-run agent session | No native agent session across jobs | |
| Team control | ||||
| Shared team process | No shared run process | Reusable saved automations | Shared jobs and workflows | Shared workflow definitions |
| Configuration in code | No versioned workflow definition | Usually configured in provider UI | Workflow files in the repo | Workflow YAML in the repo |
| Model choice | Agent's supported models | Provider-supported models | Chosen in the agent call | |
| Agent-ready external tools | Engineer adds MCP servers | Small native action set; MCP for more | Agent tools need custom wiring | |
| Tool credentials and scope | Personal credentials | MCP often uses personal OAuth and grants all server tools | Secrets passed to jobs | |
| Visibility and cost | ||||
| Activity logs | No shared run history | Automation session logs | Workflow and job logs | |
| Model cost by task | No shared cost per task | Usage in provider account | Model cost separate from runner usage | |