Technical details
An agent works in your code. A person checks every change.
Squirrel takes one work item from your Plane backlog, works it in a fresh git worktree on its own branch, and hands back a pull request. A Squirrel developer reviews and merges it in about 30 minutes, and the time log is committed on the branch, next to the code.
Short version, in everyday words: you write down a task, Squirrel does the work, and a person at Squirrel checks every change before it goes live. The rest of this page is the technical version of that sentence - written for a developer, a technical adviser or an IT partner who wants to check what we claim. If you only want to know what Squirrel does for your business, read the business page instead; it says the same thing without the detail.
41 PipelinePharma tasks in 42 hours of our own working time, estimated at 135 senior-developer hours.
A task in, a reviewed pull request out
There is no chat window in the middle. A work item goes in at one end and a pull request comes out at the other, with the branch, the commits and the logged time attached to it.
- The work item is the brief: its description, or the comment that starts the run. No separate prompt file to keep in sync with the ticket.
- The agent works in its own git worktree on its own branch, so your checkout and anything uncommitted in it are never touched.
- The work is committed before the session ends, and checked again afterwards with git status --porcelain, so a finished session cannot leave work in the agent's memory only.
- A second, separate session logs the time against the branch and commits the log, so the hours claimed for a change sit next to the change.
- The pull request is opened for you: gh pr create --fill, or tea pr create on a Gitea remote.
- The result comes back as a Plane comment with the branch and pull-request links, and the work item moves to your review state.
- A Squirrel developer reads the diff and merges it. The agent never merges.
What actually runs, in order
Most agent setups fail in the gaps rather than in the model: the edit that was never committed, the time nobody logged, the pull request nobody opened. Each step below is enforced by the pipeline, not left to whoever is prompting that day.
-
1
Trigger
A Plane work item, either assigned to Dumbo or explicitly mentioned in a comment. The description, or the comment that starts the run, is the instruction.
-
2
Worktree and environment
Before any model runs, a branch and worktree are created for the task and prepared over SSH: dependencies, configuration, virtual environment. Your own checkout is left alone.
-
3
Rules
Every run is sent with the platform's master rules prepended to the prompt, and that block states that it overrides conflicting project-level instructions. If the master rules cannot be loaded, the request fails instead of running without them. Your own AGENTS.md, CLAUDE.md or .clinerules still sit in the worktree and apply to the code.
-
4
Coding session
The agent runs headless and auto-approved, with a per-branch data directory and explicit provider, model, key and thinking-level settings, so two tasks on one host cannot pick up each other's configuration. The session is capped at 30 minutes by default.
-
5
Commit
The session is asked to commit, but the commit is not taken on trust: anything still uncommitted afterwards is committed from outside the agent.
-
6
Time log
A second, separate session logs the time in the same worktree and commits the log to the branch. The coding session is explicitly told not to log or mention time, so the hours attached to the pull request are the hours that were actually recorded.
-
7
Publish and clean up
The worktree is checked again with git status --porcelain, the branch is pushed, and the worktree is removed. A session that dies halfway cannot leave an unpublished branch or a stray directory behind.
-
8
Pull request
gh pr create --fill opens the pull request; on a Gitea remote, tea pr create does. A release run first merges the remote default branch into the task branch and runs the project's own tests, so conflicts surface before a human looks at the diff.
-
9
Report back
The result and its links land as a comment on the work item, and the item moves to the review state you configured.
What stays yours
You are not handing over the repository or the standards. A Squirrel developer reviews and merges every pull request.
Your conventions
Your AGENTS.md, CLAUDE.md or .clinerules are in the worktree and apply to the code. Only a direct conflict with the master rules is resolved against them, and the prompt says so instead of leaving it to chance.
Your models
The processing mode is a per-project setting. EU mode sends every request to OpenRouter's EU endpoint and refuses any model that is not on the EU list; global mode passes a provider allowlist instead. Your key, your choice.
Review and merge
A Squirrel developer reviews and merges every pull request. The agent never merges. You can review the same diff on the branch at any point.
Your changes
Comment on the work item with what should be different; the next run starts from that comment instead of from a fresh prompt.
Your repository
Access that lets us open pull requests; a deploy key alone is not enough. Nothing has to be installed in your repository: setup and teardown are commands the pipeline runs, not hook scripts committed to your tree.
Your task shape
A task a senior developer would scope at one to eight hours. Bigger work is split into tasks first, which is also what keeps each pull request reviewable.
What it will not do
The guarantees worth reading are the negative ones.
- Merge. Pull requests only: the merge is a person's decision and a person's click.
- Silently lose a session's work: the worktree is checked with git status --porcelain and anything left over is committed before the branch is published.
- Leave a worktree behind: it is removed once the branch is pushed.
- Put the time log in your tracker: logging is its own session, time-log wording is stripped from the comment, and the log goes to the branch and the developer email.
- Fall back to the global endpoint in EU mode: a model that is not EU-eligible fails the task, with its name in the message, instead of switching quietly.
- Run without its rules: a missing rules file fails the run before the model starts.
Where the code and the requests go
Your code is handled on MB Pikutis' own infrastructure: a Tier-3 data centre in Vilnius and the company's own data centre in Kaunas. MB Pikutis holds ISO/IEC 27001:2022 (LST EN ISO/IEC 27001:2023) certification covering the development, deployment and maintenance of web and mobile applications and the provision of hosting services - certificate No. 251.2718, valid until 22 December 2028, certified by UAB SERTIKA.
Model inference runs through OpenRouter, on the endpoint the project is configured for. In EU mode requests go to https://eu.openrouter.ai/api/v1, and every configured model - the primary and each fallback - is checked against OpenRouter's EU model list before the run; router/auto models and the batch API are refused, and the fallback has to be served by a different provider than the primary. In global mode requests go to OpenRouter's global endpoint with a provider allowlist.
No API key is hard-coded in the pipeline or printed into its logs. Worktrees are deleted when coding is done and repository access is revoked when a client project is closed, and what we build for you is yours.
The detail lives here: Security, Privacy, Data processing agreement
Every deployment is scanned for known security problems
Before a change goes live, the image that will run it is scanned in our Harbor container registry. Every image we deploy is scanned, and an image that fails the scan is not deployed.
The scan looks for known security problems in the image - the parts it is built from and what they are known to contain. It is a check for known problems, not a claim that any deployment is free of vulnerabilities, and it does not replace the person who reads the change.
We do not publish the name of the scanner, the pass thresholds or how often the scan runs: those are settings of the registry that can change without the service changing.
Where this is not enough
Read this before the demo. It is a small, reviewed unit of work, not a team.
Review is the ceiling
Every pull request waits for about 30 minutes of a Squirrel developer's review. That review is inside the logged hours, so it is paid for, not free - and it is the step that limits throughput.
Task shape matters
Best on tasks a senior would scope at one to eight hours. Hand it a vague epic and you get a vague pull request; the splitting is part of the work.
Two trackers, two git hosts
Plane for work items; GitHub or Gitea for pull requests. There is no Jira or Linear path in this pipeline today.
EU mode is a whitelist
It guarantees the endpoint and that the models are on OpenRouter's EU list. It does not answer every residency or retention question about a given provider on its own - ask us the specific one you need.
Judgement stays human
The agent executes a scoped task. Architecture, product decisions and the final call on what ships stay with your team.
Timing is typical, not guaranteed
Deliveries are usually same-day. A queue, a platform outage or a task that turns out to be larger than scoped moves that.
Build the pipeline yourself, or rent it
Most of this page is reproducible: the tools are open, and the worktree-to-pull-request loop is a good weekend of scripting. The honest difference is everything you would then have to keep running.
| What it takes | If you build it yourself | With Squirrel |
|---|---|---|
| Starting a task | Paste the ticket into a chat window and paste the diff back by hand. | Assign the work item to Dumbo, or @-mention it in a comment. The ticket is the brief. |
| Isolation | Let the agent edit your working tree, then check what it left behind. | A fresh branch and worktree per task, removed after the branch is published. |
| Rules and standards | Re-paste your conventions into every prompt and hope they stick. | Master rules injected on every run, with your repository's own agent files still applied. |
| Staying on top of main | Fetch, merge, resolve the conflicts and re-run the tests yourself. | A release run merges the remote default branch into the task branch and runs the project's tests before the pull request. |
| Work that was never committed | Discover at git status that the session edited files and committed nothing. | The worktree is checked with git status --porcelain and anything left over is committed before publishing. |
| The pull request | Write the description from memory, or from the diff. | gh pr create --fill (or tea pr create), then the result and the links land as a comment on the work item. |
| Model data path | Whatever your gateway defaults to, plus the proof that it stayed there. | A per-project EU or global mode, with every model validated against OpenRouter's EU list before an EU run. |
| Time accounting | Guess how long the run took, after the fact. | A separate session logs the time and commits the log to the branch with the code. |
| Review | You read every diff, or something ships unreviewed. | A Squirrel developer reviews every pull request (about 30 minutes) and merges it. |
| Keeping it alive | You own the runners, hooks, secrets, retries and the person who understands them. | Hosted: from €1,880 a month for 16 logged hours; extra hours €55. |
The left-hand column describes the work, not a competitor. Plans: Starter €1,880/month with 16 logged hours (setup €490); Team €2,908/month with 36 logged hours (setup waived for a three-month minimum); extra hours €55; prices exclude VAT; AI usage up to €150 per project per month is included.
What Squirrel does, and what it does not do
The short list we expect to be held to. Both halves are part of the service.
Squirrel does
- Works each task on its own copy of the code, on its own branch, so your own working copy and anything uncommitted in it are never touched.
- Runs the project's own automatic checks before a person looks at the change.
- Puts every change in front of a Squirrel developer, who reviews it and decides whether it goes in.
- Records the time spent on the task next to the change, so the hours can be checked against the work.
- Scans the container image for known security problems before deployment and stops an image that fails the scan.
- Routes model requests only through the EU or the global endpoint the project is configured for, and refuses a model that is not allowed there.
Squirrel does not
- Does not merge its own work: merging is a person's decision and a person's click.
- Does not invent the scope. You write the task; we build what it says, not what we would have picked.
- Does not replace a team. It is one small, reviewed piece of work at a time.
- Does not promise software free of vulnerabilities. The scan finds known problems in the image; it cannot prove that code is safe.
- Does not leave a working copy of your code behind: it is deleted when coding is done and access is revoked when the project closes.
- Does not switch models quietly in EU mode. A model that is not EU-eligible fails the task and says so.
FAQ
Questions developers ask first
The objections we hear from the people who will actually read the diffs.
-
Do you get merge access to main?
No. We need access that lets us open pull requests; a deploy key alone is not enough. The agent never merges: a Squirrel developer reviews and merges every pull request, and your branch protection rules stay in place.
-
Which model actually runs my code?
Whatever the project is configured with: a primary model and its fallbacks, validated before the run. In EU mode every one of them has to appear on OpenRouter's EU model list, and auto-routing models and the batch API are refused. We do not publish a fixed model list, because it changes faster than a page does.
-
What happens if the pull request is wrong?
Comment on the work item with what should be different. The next run starts from that comment, on the same branch, and the diff stays reviewable the whole way.
-
Does it touch my working copy?
No. The work happens in its own branch and worktree, created and torn down by the pipeline, so uncommitted work in your checkout is never at risk.
-
What has to be installed in my repository?
Nothing. Environment setup and teardown are commands the pipeline runs over SSH, not hook scripts committed to your tree. If you already keep AGENTS.md, CLAUDE.md or .clinerules, they are respected. No board or repository yet? We set both up for you, and the CI/CD pipeline and staging environment come with them.
-
How is the time measured?
A separate logging session records it against the branch and commits the log with the code, so the hours claimed for a change can be checked against the change itself.
-
Can I see what the agent actually did?
The Plane comment carries the result plus the branch and pull-request links. The pull request carries the commits and the diff, and it is the same diff the reviewer read.
-
What does it cost?
From €1,880 a month for 16 logged hours, with extra hours at €55; the review is inside those hours. Team is €2,908 a month for 36 logged hours. Setup is a one-off €490, waived on Team for a three-month minimum. Prices exclude VAT.
-
Where does GitHub Copilot fit?
Copilot is a tool for developers you already employ: its coding agent can pick up an assigned GitHub issue and open a draft pull request, and Copilot supports EU data residency on GitHub Enterprise Cloud (checked against public GitHub documentation, November 2026). It still needs someone to scope the task, review the diff and answer for it. Squirrel supplies that someone.
-
What happens to my repository and hosting when we stop?
You keep the repository and the deliverables. Worktrees are deleted when coding is done and our repository access is revoked when the project is closed. Hosting is separate: staging and production hosting continue on MB Pikutis infrastructure for as long as you want them.
Case study spotlight
Proof from delivered work
Website tasks delivered
PipelinePharma: 41 tasks delivered, every one reviewed
A list of website tasks delivered in 42 hours of work, with every change checked by a person before it went live.
3.2x faster on 41 tasks, measured on one project
42 hours of our work replaced an estimated 135 hours of senior-developer work.
From prototype to app
Amber Beaches: from a prototype to a working app
An AI-built one-page prototype became a working app with a public site and a staff area, without throwing the original screens away.
26 tasks, about 10 h of our working time
Against an estimated 33 hours with AI and 115 hours without it.
Send a task, read the pull request
One work item is enough to judge this. Send up to three and we will come back with a scoping estimate, or book a demo and watch a task run end to end.