AgentPilot: a distribution named src, a Python pin to one patch, and binaries on SourceForge

The Poetry project is named src, so the distribution is called src

The packaging manifest names the project `src`.

That is the literal name in the project table, sitting next to a description that reads create, manage, and chat with AI workflows, and a version of `0.5.1` that matches the newest release. The author field is a single name and a Gmail address at the project's own domain.

So the artefact name, the repository name, the application name in the interface, and the site are four different strings, and the one in the manifest is the least meaningful of them. Anyone running `pip install` from this project would get a distribution called `src`, which is also the name of the directory holding the code, which is why the mistake is easy to understand and easy to miss: nothing in a source tree named `src` looks wrong until you look at the built artefact.

It matters for anyone scripting an install or pinning a hash, because the string in the lock file is the string you have to reproduce.

The rest of the manifest is otherwise conventional for a Poetry project, with poetry-core as the build backend and a long dependency list that is the subject of the next two sections.

Every requirement carries a marker for exactly CPython 3.10.11

The interpreter constraint is a single patch version.

The manifest declares the Python requirement as `3.10.11`, not as a floor and not as a range. For a Poetry project that is an exact constraint, and the exported requirements file shows the consequence: essentially every line ends with an environment marker conditioning it on the full version being `3.10.11`, and platform-specific packages add a second marker for Windows or Darwin or Linux on top of it.

A lock file generated under that constraint is only valid for that interpreter. Move to 3.10.12 and every marker stops matching, so the resolution is not a slightly different set of packages, it is a different resolution problem. Move to 3.11 and the file describes nothing at all.

That is an unusual amount of coupling for a desktop application distributed as prebuilt binaries for three operating systems. The reason for it is visible in the manifest: several dependencies are pinned to exact versions rather than ranges, including the GUI toolkit, the model gateway, the structured-output library and the container client. Exact pins on transitive-heavy libraries are what force the lock file to be interpreter-specific, because a single patched release of any of them can change what resolves.

The visible documentation does not discuss the interpreter requirement beyond pointing at a build guide for compiling from source.

Binaries are hosted on SourceForge with MD5 and SHA1, and there is no Apple Silicon build

The quick start does not point at GitHub releases. It points at a third-party file host.

Three archives are listed, all under version 0.5.1: a Linux tarball, a Windows zip, and a Mac Intel tarball. Each is linked from a files area on SourceForge, and each is published with exactly two digests, an MD5 and a SHA1, printed next to the download link.

Both of those hash functions are broken for adversarial use. MD5 is collision-broken and SHA1 has a practical collision demonstration. They remain useful for spotting a truncated download, which is probably the intent, and neither is useful for confirming that an archive is the one the maintainer built.

The platform coverage has its own gap. There are Linux and Windows builds and a Mac build labelled Intel. There is no Apple Silicon entry, so on a current Mac the only provided binary is a different architecture, which means emulation or a build from source.

A compile-from-source guide is linked for that case, and the root carries a build script, a packaging spec and two icon files in the formats macOS and Windows expect, which is what a self-contained desktop bundle looks like.

So the verification chain for a user who does not compile is: download from a file host, check two weak hashes, run an unsigned application that can execute generated code.

A SQLite database is committed at the root, and the upgrade path is swapping the executable

The root entry list includes `data.db`.

A binary database file tracked in version control is either a seed that ships with the app or a file that should never have been committed. The documentation suggests both are in play: the application is described as persisting memory and state through Python modules imported at runtime, and the migration guidance is given as a tip rather than a procedure.

That tip says you can migrate your old database to the new version by replacing your executable with the new one before starting the application.

So the upgrade path is: keep the file, swap the binary, start. No schema step, no export, no import, no backup instruction. For an application whose whole value is accumulated workflows, chats, custom pages and configuration, that is a remarkably thin migration story, and it is also the reason a committed database file is hard to reason about, because the thing being migrated and the thing that migrates it are both just files on disk with no version negotiation visible.

The default branch is named `master` rather than `main`, which is worth a note only because it is the kind of detail that breaks clone instructions written from memory.

The newest release is from May 2025 and the last commit is from April 2026

Two dates, and the gap between them is the story.

The newest published release is v0.5.1, dated 2025-05-15. Before it came v0.5.0 in February 2025 and v0.4.2 in January 2025, so the release line moved roughly once a quarter through 2025 and then stopped.

The last push to the repository is 2026-04-14. That is close to six months ago, and just inside the six-month mark at which a project starts looking abandoned by most measures. It is not an archived repository.

So there is roughly eleven months of commits after the last release. Whatever the source contains today is not what any of the three published binaries contains, and the version in the manifest, 0.5.1, is the released version rather than a description of the tree.

For someone deciding whether to use this, the practical question is not whether the repository is alive but which code they would be running. The binaries are a year behind the source, and the source has had no tagged point since May 2025 to pin to.

The repository also carries a changelog and a contributing guide, so the history of those eleven months may well be documented even though it was never cut as a release.

One AI generation block shipped, two of four plugins are disabled, and the scheduler is premium

The feature list is long and the working subset is shorter, and the page is honest about which is which.

Under AI generation, four system blocks are offered. AI enhanced user input ships. AI generated agent, AI generated system message and AI generated page are each marked coming soon. So a quarter of that section works.

Under plugins, four entries are listed: an agent plugin with Open Interpreter and an OpenAI Assistant, and a workflow plugin, plus a provider plugin for LiteLLM. Of the named third-party integrations, both CrewAI entries, an agent and a workflow, are marked currently disabled. Two plugin links point at bare site roots rather than at anything specific.

The scheduler, which is one of the more interesting capabilities, is labelled Premium: run at specific times or intervals, with natural language expressions, and the page's own example ranges from every five minutes to every second Tuesday of the month, with the introduction claiming scheduling from every second to every leap year. All of that is behind a paywall.

Voice is a fourth case. It is headed coming back soon, and the line under it is struck through and cut off mid-sentence in the visible text.

None of this is deceptive, since each gap is labelled. It does mean a reader sizing the product from the headings will substantially overestimate it, and the strikethrough line suggests features have been removed rather than merely deferred.

Auto-run generated code in nine languages, with a mouse and keyboard library as a hard requirement

Code execution is not a plugin you opt into. It is a member type.

Open Interpreter is integrated and can execute code in nine languages, named as Python, Shell, AppleScript, HTML, JavaScript, PowerShell, R, React and Ruby. Code runs from any Code member inside any workflow, whether that workflow is a chat, a block or a tool, and also from a message carrying the role Code. For code messages, auto-run can be switched on in settings.

The page's own warning is the right one and it is short: you should always understand the code being run, and anything you execute is your own responsibility.

What makes that more than boilerplate is the dependency list. `pyautogui` is a required dependency, not an extra, and it is a library for programmatic control of the mouse and keyboard. A workflow member that synthesises input events can drive the desktop the application is running on, which on macOS means the app needs accessibility permission and on Windows means it acts on whichever window is in front.

So the combination is: a language model proposes code, auto-run can execute it without a confirmation step, and the runtime can move the pointer and type. On a machine with a password manager, an SSH session or a cloud console open, that is a meaningful exposure, and it is the kind of thing that belongs in an installation checklist rather than in a feature list.

The counterweight is that this is a desktop automation product, and synthesising input is what those products are for.

Rewinding execution is the real idea, and the voice client library outlived the voice feature

Two things close the picture, one a strength and one an oversight.

The strength is the execution model. Branching workflows let messages, tools and code be edited and re-run, so a conversation is a tree rather than a transcript. Tool parameters can be modified at runtime and re-executed, which the page describes as creating a branch point you can cycle through. Graph workflows place members vertically to run them in parallel, and the member list includes User, which waits for you, alongside Agent, Text, Code, Prompt, Module and Workflow. Workflows nest without a stated limit.

Rewinding a tool call and re-running it is the feature that most chat interfaces lack, and it changes what you can debug.

The oversight is in the dependency list. Voice is marked as coming back, and the sentence under it is struck through. Yet `elevenlabs` is still a hard runtime requirement in the same list as the GUI toolkit and the model gateway, and a commented-out line above it points at a sound dependency with a note about audio. So the text-to-speech client library is installed on every user's machine for a feature that is currently switched off.

Posthog is also a hard runtime dependency rather than an optional one, which means the packaged application carries an analytics client. The visible documentation does not say what it sends or how to turn it off.

There is a credential library too, which is the right choice for storing model keys, and it is worth remembering when reading the code-execution section above.

Editorial conclusion

Use AgentPilot if you want a local, rewindable workflow canvas and you are willing to run it on one machine with your own model keys, because the execution model is genuinely more flexible than a chat log and nothing leaves your machine by design. Do not build on the published binaries without hashing them yourself, since they are hosted off the forge and published with two weak digests, and treat the 2025 release as the ceiling of what is actually shipped rather than the last commit. Two decisions to make first: whether auto-run of generated code in nine languages is acceptable on a machine holding real credentials, given the input-synthesis library in the dependency list, and whether the features you want are the ones marked as coming soon or disabled, because the feature list is considerably longer than the working surface.

Frequently asked questions

Official sources

1. jbexta/AgentPilot on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases