I built polylinedb so my local tools and cloud agents can use the same tasks and project knowledge.
It runs in my own Cloudflare account, with a CLI for local agents and remote MCP for cloud agents.
Version 0.1.0 is now available on npm.
The problem I wanted to solve
I have been using herdr to work with local agents. I build several tools and use one while developing another.
When I find a bug or an awkward workflow, I want to keep the finding for the next change.
A useful constraint or design decision needs to survive the conversation that produced it too.
Adding cloud agents exposed a problem with where those records lived.
I wanted to investigate locally, hand a task to a cloud agent, and review its progress from my laptop.
A record in my local checkout could not serve every environment.
I also wanted to avoid pulling and pushing a separate copy whenever I moved work.
So I built a store that my local CLI and cloud MCP connectors can both use.
A store my cloud sessions can reach
Suppose a local agent discovers that empty input causes a failure. I want it to record the finding in an issue. A cloud agent can then read that issue before working on a fix. Later, I want to inspect the same record from my laptop.
I use the cloud database as the main store for records shared with cloud agents.
My local CLI reads and writes that same database.
A Cloudflare Worker accepts HTTP requests from the CLI and remote MCP calls from cloud hosts.
D1, Cloudflare's serverless SQLite service, stores the records.
An agent can create an issue, search earlier findings, append a comment, or update progress through either interface.
The records remain available when I change hosts or start another session.
That is the reason for the cloud-first design: the store must be reachable from wherever the next agent runs.
Keep knowledge after a task closes
Tasks record work to do. Memory retains findings that later work needs.
During a migration, for example, I may confirm that IDs, authors, and timestamps must survive the move.
After the migration task closes, that constraint can remain in project memory for the next agent to retrieve.
With an authenticated connection named cloud, the CLI can retrieve both kinds of record:
# Find the project's unfinished work
pd --connection cloud list --project demo --status open
# Retrieve the knowledge saved for that project
pd --connection cloud memory context --project demo
Cloud agents can retrieve the same records through MCP.
The bundled skill tells agents to retrieve project knowledge before work and after context recovery.
Retrieval is explicit, and the saved text cannot override the user's instructions.
This also fits how I develop my tools.
Feedback becomes a task, while a confirmed finding can become memory that later work reuses.
Knowledge belongs to a selected project. I can use a common project for facts that several tools need.
A personal deployment on Cloudflare
I wanted a store I could operate in my own account without maintaining a database server.
Cloudflare provides the Worker runtime, D1, and Access.
I manage the polylinedb application and its access settings.
I enjoyed using the cf CLI for setup.
I could create resources, deploy the Worker, and configure Access without repeating those steps manually in the dashboard.
The deployment guide records the procedure for another person's account.
Access handles OAuth authentication, and polylinedb checks the authenticated identity against its store allowlist.
The connector host manages the cloud agent's OAuth credentials.
I do not put a client secret in a prompt or hand the agent a Cloudflare Service Token.
The local CLI uses browser login and stores credentials in macOS Keychain or Linux Secret Service.
Expired or revoked authorization can require another login.
Local SQLite mode is available too. It opens one file outside the working repository and needs no server.
It is an independent store, with an explicit migration path to the cloud.
For shared records, my laptop uses the cloud connection rather than a synchronized local copy.
When agents write at the same time
Several agents may read the same issue before any of them changes it.
If one changes the body, another cannot overwrite that change using an older version.
polylinedb rejects the stale update so the agent can read again and reconsider.
Different issue fields have separate versions, while each memory entry has one version.
Creation also recognizes retries, so a lost response need not produce a duplicate task.
These choices account for agents that work concurrently and make requests over a network.
My experience so far is personal development with multiple agents. I have not tested operation by multiple people.
Ready for my personal development
In my deployment, Cursor Cloud, Codex Cloud, and Claude created issues, read them, and added comments through MCP.
Grok Bot shared Cursor's authentication and read existing issues.
Local Codex, Claude Code, and Cursor used the CLI to read and write records in the same cloud store.
I also checked memory operations through the CLI and MCP, then independently inspected the saved results in D1.
The checks covered reads, writes, conflict rejection, and behavior after deletion.
I moved my personal issues from Beads, then moved my shared local records into the existing cloud database.
I compared the complete result before changing each project's selected store.
The migration guide records the one-time conversion.
Those checks establish access and record behavior in my environment.
A formal experiment that hands work between local and cloud agents in both directions is still planned.
Automatic memory hooks and update notifications also remain future work.
Try it with your agents
polylinedb means polyline database. Its command is pd, and version 0.1.0 is available under the MIT license.
The README covers local use, and the deployment guide covers a store in your own Cloudflare account.
npm install --global polylinedb
I now keep my tools' tasks and project knowledge in this store.
When I start another session, the agent can retrieve the records that earlier work left behind.
If you work with both local and cloud agents, I would like to hear which parts of that transition still cost you effort.
Top comments (0)