Count the tools you signed up for last year. Each one probably started the same way: an email, a password, a free trial, an onboarding call. Most of them do one job: hold some structured records, check a few rules and show you a view.
Now add AI agents to the picture. If you run a team of bots, every one of those tools is another integration, another API key, another place your agents can't see. The more SaaS you have, the harder it is for agents to help.
So here's the argument. Most workflows are structured data with rules and a view on top. Agents are good at reading and writing structured data, as long as it's cheap and close at hand. I put it this way while building: "Agents need cheap structured data." A tool for agents shouldn't be one more app with a login. It should be a place any agent can read from and write to, with the rules stored right next to the data.
That's what pebblebase is meant to be, and it should work with systems like Grok Bots, the bot team I run every day. Here's how I actually use it.
pebblebase stores each tool as a pebble: one SQLite file holding your records, the rules that check them, views, forms, reminders, tests, and notes your AI reads the next time it opens it. You connect once with one MCP URL, and any connected AI picks the pebble up in a fresh chat.
My Grok Bots are a small team, each with a job: chief (the lead), product, marketing, web, strategy, a hunter that acts on approved plays, and a retro bot that reviews results. Because pebblebase is an MCP connector, I don't build a separate integration for each bot. As I told my product bot on launch day: "Since pebblebase is just an MCP, we should just have the tools to connect and you can work from any bot."
The rule for the team was simple. In my words to chief: "for things that don't live in the repo, we need to create and manage pebbles such that we all have access to pebbles."
On launch day I set a goal: "We want 100 die hard users. That's a goal. So what are we doing about it?"
That goal became pebble100. It holds one goal row, a list of strategies (the bets, each with a hypothesis) and a list of actions. Strategies can't be deleted, only retired, so past actions keep their history.
The key rule is that every action gets logged, by whoever did it. I told my product bot: "we basically want to log any action take toward that goal. That way we are capturing qualitative data. Our other systems provide the quantitative data." The log has a done_by field, and today it has entries from me, from the product bot, and from the two of us together. I don't like collecting user data, so pebble100 only records what we did and what we learned, never tracking data.
Every Friday at 4 PM, pebble100 sends a reminder to my phone. I open my AI chat and ask it to run the check-in. The bot:
That's the loop pebblebase is built around: set a goal, the AI builds the log, a reminder brings you back, the AI reads it back.
The same pattern runs a bigger KPI pebble, framed as Goal → Strategy (plays) → Actions → Guardrails → KPIs. The roles are written into the pebble:
Every action by any bot or by me is a row, and the action log is append-only. The guardrails are rows too. If a play misses its target too many periods in a row, the pebble refuses a "continue" decision, and the play has to be changed, paused or killed. To change the policy, you edit a rules row.
Gaps is the ranked backlog of features, bugs and improvements for pebblebase. Items and updates are append-only, and resolving an item requires a note saying what changed. When I sketched what the team needed, it was "Basically just the Stateman and Gaps."
Gaps also has a work table: one row per gap, session and pull request, with the agent that did the work and its token counts. There's no cost column because, as the pebble's notes put it, "tokens are measurable, cost isn't." Right now it has 45 work rows, all from Claude Code, against 34 resolved gaps, 3 in progress and 40 open.
pebbleCRM holds companies, contacts, deals, interactions and follow-ups, with a pipeline board and a "Due now" view. To be straight with you: mine has no real records yet, so I can't show you a pipeline. What it shows is that a CRM is a schema, some rules and a few views. When a bot needs one, it can use the same connector it uses for everything else.
This post came out of a pebble too. One of my bots reads my bot transcripts and logs "nuggets" into a pebble called Nuggets: a real quote, where it came from, and whether it's OK to share. It groups nuggets into story ideas and saves drafts in the same file. Each claim here traces back to a row with its source. That bot doesn't publish anything; I read and approve.
Each pebble is the same idea applied again: define the system first, put the rules in the data, and let the bots do the typing. After watching a bot model a real business operation in one sitting, my takeaway was: "we can model operations insanely fast. What we actually need is to define our system first." When I hand work to a bot, I ask it to "keep this scoped to what we need."
What you give up: no polished vendor UI and no integrations marketplace. What you get: one shared place every bot can read and write, rules enforced by the data instead of by memory, and files you can export.
pebblebase is a free pilot. There's no card and no email: you connect your AI (Claude, ChatGPT, Grok or Codex) with one URL and create an account with a username and a passkey. Then you describe a tool in your own words, or point your bots at it.
If you run agents and your data is scattered across apps they can't see, try giving them one pebble to share. Start at https://pebblebase.dev. If it's useful, I'd like to hear what you built. If not, I'd like to hear that too.