Shipfox

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.

Compare approaches to engineering work
Comparison pointLocal coding agentAgent automationsCI platformShipfox
Example providers
Products
Running work
Where code runsEngineer's machineProvider-managed cloud runnerHosted or self-hosted runners
Execution environmentNo runner choicePreset runner environmentCustom runners, images, and network
Parallel workNo managed parallel jobsParallel managed runsParallel jobs within runner capacityParallel jobs by default
TriggersHuman starts a sessionProvider-supported events and schedulesRepository events, schedules, and webhooks
Coordinating agents and steps
Later review commentsEngineer follows up in chatNew automation runNew workflow run
Failed check needs a code fixEngineer prompts another attemptNo independent feedback gateChecks fail jobs; no built-in agent repair
Agent and fixed steps in one flowNo workflow orchestrationNo built-in mixed-step workflowAgent call needs job scripting
Agent conversation across stepsNo shared workflow sessionNo cross-run agent sessionNo native agent session across jobs
Team control
Shared team processNo shared run processReusable saved automationsShared jobs and workflowsShared workflow definitions
Configuration in codeNo versioned workflow definitionUsually configured in provider UIWorkflow files in the repoWorkflow YAML in the repo
Model choiceAgent's supported modelsProvider-supported modelsChosen in the agent call
Agent-ready external toolsEngineer adds MCP serversSmall native action set; MCP for moreAgent tools need custom wiring
Tool credentials and scopePersonal credentialsMCP often uses personal OAuth and grants all server toolsSecrets passed to jobs
Visibility and cost
Activity logsNo shared run historyAutomation session logsWorkflow and job logs
Model cost by taskNo shared cost per taskUsage in provider accountModel cost separate from runner usage
Was this page helpful?
Edit this page on GitHub