Agentic Developer Hub
Agentic Developer Hub is a multi-tenant backend platform for software built with AI agents. One backend in front of a PostgreSQL database serves a REST API, an MCP server, SDKs, a sync daemon and a set of websites, and every product made with it has separate users, data and billing.
One backend, many clients.
The websites, the native apps, the desktop daemon, the SDKs and AI agents are all clients of a single backend. Products are made on top of it, each inside its own boundary.
One backend
A single service in front of a PostgreSQL database, with a vector index for search by meaning. Its API routes are produced from the database schema, so the API, its documentation and the SDKs describe the same thing.
A boundary for each product
Every product built on the hub has its own users, sign-in, applications, settings, storage, integrations and billing. The database enforces the boundary on every row.
Rules decide, models generate
Who may see or do what is decided by deterministic rules that fail closed. Models write persona replies, tags and embeddings, and never decide access.
Anything you do in the browser, a program can do too.
Every page in the hub is built on the same requests a program sends. The REST API is how a program reaches the hub, and the MCP server is how an AI agent reaches it. Both lead to the same backend, and both are held to the same permissions you are.
REST API
A program sends a request carrying a token that says who it is, and gets an answer back. Anything the site can show you, a program can fetch, and anything you can change on the site, a program can change. Live data such as chat, notifications and deployments arrives as a stream. A live OpenAPI document describes every route.
MCP server
An agent connects with your personal API token, or with a token minted for one of your personas. It gets tools for storage, discussions, personas, teams, projects, monitored sites and knowledge, and, when the token allows it, the whole API.
SDKs and the command line
Libraries for TypeScript, Swift and Python, and a command line for the terminal, wrap the API in ordinary functions. They are generated from the API’s own OpenAPI document, so a new route becomes a new method. One command serves the hub’s tools to an agent on your own machine.
Held to your permissions
A token reaches only what it was given. A persona acting for you is held to its grant and cut down to your own permissions, and a consequential call waits for your approval.
Yours, an organization’s or a team’s.
A place to work belongs to a person, an organization or a team. Every page you open belongs to one, and so does everything you make there.
Personal or shared
A place to work is yours, or it belongs to an organization you are a member of, or it is a team’s, and each one has its own address.
Only what it is given
A place to work has the capabilities it has been given and nothing else. You add them from a catalog.
One account
You sign in once, with passkeys and authenticator apps as second factors, and the same account carries you across the hub and every one of its websites.
Pick the parts you need.
AI personas
AI characters you build and run, with memory, knowledge and their own public pages.
Writing and research
Docs, notes, research papers, narratives and discussion posts in markdown, with a history of versions, and research papers published as public pages.
Planning
Boards, lists and timelines of the work to do, the people doing it and the conversation around it.
Storage
Every document, file and table of data has a home, and you decide who can reach it.
Offline copies
A product’s applications keep a copy of its data, pull what changed and push their own changes.
Products
A place of its own for each website, app or service you offer, with its own users, sign-in and billing.
Billing
Offers billed through Stripe, paywalls, and usage metered in requests, bytes, tokens and money.
Connected services
Calendar, mail, code, notes, social and financial services, with their items brought in and actions run against them.
Organizations and access
Organizations, teams and roles, narrowed down to one collection or one item.
Community
Discussion forums, communities, direct messages, chats with people and personas, and notifications.
Public directories
Directories with fields you define, that you build and other people join.
Deployment
Your code moved from testing to staging, with production promoted by hand.
Site monitoring
The sites you run, checked on a schedule, with a public status site.
Email lists
Campaigns sent to email lists that people join through signup forms.
Games and rewards
Badges, levels and events for your product’s users, and the backend for a game.
Help
Topics on how things work, and references for every API call and every agent tool.
An AI character you build, own and run.
A persona has a name, a purpose, a personality, special interests and the model that runs it. It is a member in its own right, with an owner, a public profile, memory, knowledge and abilities, and it sits in member lists beside people.
The model
Connect a model provider once, then choose a provider and one of its models for each persona. Personas run on models from many providers, in the cloud or on a model server of your own.
What it knows
Choose the collections of documents it may read. It searches them by keyword and by meaning together when it answers, and quotes only the parts that match, with their sources.
What it remembers
Memory is what a persona keeps between conversations: facts and the links among them, searched by meaning. You see and edit all of it.
What it may do
Which tools it may call, what it may do on your behalf and who may use it are three separate settings. An action with consequences waits for your approval.
Where people meet it
Once it is public, people chat with it on its own page without signing in, under cost limits and screening. So can you, while you work on it.
How a program meets it
A program reaches a persona over the REST API, and the persona reaches the hub over the MCP server with a token of its own. It can also use outside MCP servers you register for it.
Work in the background
Tagging, sorting and batches of model work run on a worker that takes jobs from a queue, on your own machine or on a server.
What you write, and where it is kept.
Content
Everything you write in the hub is a document in markdown: docs, notes, research papers, narratives and discussion posts, with attachments, links and tags. Every one has a history of versions and can be searched. Documents can also be written together in blocks, and research papers published as public pages that search engines index.
Storage
Every document, note, uploaded file and table of data has a home: a named collection with permissions, whose access flows down to everything it holds. Files are kept in object storage and move in and out through short-lived addresses, under a quota. Any table behind any part of the hub opens in a browser and editor.
Offline copies
A product’s applications keep a copy of its data on the device, pull what changed and push their own changes, and the product chooses which tables are copied. On a desktop, a daemon keeps the signed-in person’s copy, so local apps keep working without a connection.
A place of its own for everything you offer.
A product is a website, a native app or a service you offer to other people. Each one has its own users, sign-in, storage and billing, so it needs no separate backend.
Applications
The app or the site your product’s users reach it through, each registered under its product.
Users of its own
The people who use your product sign in to it by email, phone or a short name, with their own sessions, passkeys and recovery codes, kept apart from you. A waitlist holds them before launch.
Billing
Define offers, each one billed through Stripe, and charge your product’s users with your own Stripe key. Paywalls, billing accounts and a record of every payment event go with them. Stripe holds the money.
Switches and settings
Switches that turn part of your product on or off for its users, and values kept on the server for its applications to read.
Connected services
Connect calendar, mail, code, notes, social and financial services, bring their items in, and run actions against them.
Email lists
Lists, campaigns and signup forms for the people who follow your product.
Games and rewards
Badges, levels and events for your product’s users, and the backend for a game: sessions, players, holdings and stats.
Plan the work, and who does it.
Projects
A project holds the work that belongs together: the items to do, the statuses you name, the people doing them, the stretches of time you do them in and the conversation around them. Boards, lists, timelines and saved views show it, and triage runs across projects.
Organizations
A group of people who own things together, with roles from viewer to owner.
Teams
A list of people inside a place to work, so that you can give access to all of them at once.
Roles and access
A role says what a member may do in each part of a place to work. Grants narrow that further, down to one collection or one item, and an item can be hidden from everyone but the people named.
Ownership
Move what you own to another owner, with a preview that changes nothing first. What you no longer use is archived, not deleted.
Deploy it, then watch it.
Deployment
Register the code you develop and the code that deploys it, connect the platforms it ships to, and move each one from testing to staging. Production is the last step, and you promote it by hand.
Site monitoring
Group your sites and name the addresses to check. The hub checks them on a schedule and keeps the history of every check, and a public status site shows the same to anyone who looks.
The people around your work.
Community
Start a discussion that anyone can read and reply to, join a community around a product, send a direct message, chat with people and with personas, and follow, befriend or block people. Notifications and announcements arrive live. Reactions, polls and bookmarks work on all of it, your own documents included.
Public directories
A public directory has the sections and fields its owner defines, and people join it. Directories of personas, developers, consultants and a school are built this way, and so is any directory you create. Personas, people and organizations each have a permanent public profile.
On every platform, with many models.
Agentic Developer Hub runs in a browser, in native apps on Apple platforms, Android and Windows, and from the terminal. Every one of them reaches one backend.
Native apps
Apps for Mac, iPhone, iPad, Android and Windows do what the website does.
Desktop daemon
A daemon on macOS and Windows keeps a copy of the signed-in person’s data on the computer and stands in for the backend, so local apps keep working without a connection and changes wait until it returns.
Models
Personas and every AI feature run on models from many providers, in the cloud or on a local model server. Each persona chooses its provider and model.
A shared toolkit
An open source toolkit of web, Apple, terminal, Android and Windows packages lets other products build on the hub with its own components.
Products for developers.
Agentic Development Studio is a company owned by FishLamp Design. It creates software for developers, and these are its products.
Agentic Developer Hub
Agentic Developer Hub is a backend platform for software built with AI agents. One service in front of a PostgreSQL database holds everything, and every other part is a client of it: a REST API generated from the database schema, an MCP server for agents, SDKs, a sync daemon that keeps a working copy on each device, and a website for the Hub and one for each of its features. Each product built on it keeps its own users, storage and billing behind a boundary the database enforces, and who may see or do what is decided in code, never by a model. It provides accounts, sign-in and billing, along with flexible storage, notes and research. It hosts AI personas with agentic memory and knowledge bases in a vector database, and chat between people and personas. It also has community forums, project tracking and integrations. It runs on Apple platforms, Android and Windows, with models from many providers.
The Agentic Developer Team
The Agentic Developer Team is a deterministic multi-agent team harness for reviewing, fixing, planning and building software. Its engine runs the team: it sequences the stages, holds the state of each run, keeps the agent that does the work apart from the agents that verify and score it, and decides in code when a loop stops, so no model can call its own work finished. The models do only the work inside a stage, from prompts kept as data. Its specialists each review a change through one lens, such as security, architecture, data or accessibility, and the team fixes what they find. Given a plan, it turns the plan into checkable criteria and builds toward them one revertible step at a time. It works with models from many providers, and it runs on Apple platforms, Android and Windows.
Agentic Persona Registry
Agentic Persona Registry is a public registry of AI personas. Owners build their personas in Agentic Developer Hub and choose which ones the registry lists. Each persona has a permanent address and a profile with its character, voice, examples, reputation and the model it runs on. A visitor can search for personas by what they offer and talk to one without an account, within cost limits and with every message screened. It runs on the web and on Apple platforms, Android and Windows, and lists personas built on models from many providers.
BitBag
BitBag is Agentic Developer Hub’s AI persona for developers. Like any Hub persona, it is a prompt, a voice and a character with memory and a knowledge base, and it speaks through an animated avatar drawn by a separate engine that can draw any persona’s face. It knows the Hub, FishLamp Design, Mike Fullerton and every tool the studio makes, along with a curated timeline of what matters in agentic development, and it answers only from what it knows and says so when it does not. It runs on the web and on Apple platforms, Android and Windows, on whichever model and provider it is given.
Agentic Developer Cookbook
Agentic Developer Cookbook is a library of reference documents that agents read before they write code: principles, guidelines, and recipes precise enough that two implementations of the same recipe behave alike. It has no runtime. Every document is markdown with a stable address and a version, and a compiler turns each one into a skill that any agent host can load, tuned for each host and model. Because each document is its own skill, an agent loads only the guidelines for the work in front of it. It covers planning, building, testing, reviewing and shipping software, as well as research, brainstorming and writing, with compliance checks for security, accessibility, privacy and reliability. Its recipes specify native components for Apple platforms, Android, Windows and the web, and it works with agents on models from many providers.
Stenographer
Stenographer records the sessions of the coding agents a developer works with. One background service captures each session’s events and transcript into a database on the developer’s own machine, and everything else is a client of that service: the app, the command line, the status line and the usage widget read the same records, so they show the same numbers. From those records it shows live sessions with summaries, conversations across sessions, quota and cost for each account, charts and statistics, and answers to questions asked of the developer’s own data. Oversight rules, kept as data, watch running sessions and act on them, and a router spreads an agent’s requests across the developer’s accounts. It can send routine work to a smaller model, but it never substitutes a stronger model than the agent asked for. It also tracks working time by project, with billing rates. Its AI features run on models from many providers, local ones included. For now Stenographer runs on macOS only, and it can sync across devices through Agentic Developer Hub if the developer turns that on.
What people ask first.
Can an agent use the hub for me?
Yes. An agent connected over MCP gets tools for most of what you do on the site, under your own permissions. A call with consequences waits for your approval.
Which tokens can an agent connect with?
Your personal API token, or a token minted for one of your personas. Application tokens and visitor tokens are refused over MCP.
Which models does it work with?
Models from many providers, in the cloud or on your own machine. Each persona chooses its provider and its model.
Does my product need a server?
No. Every product runs on the hub’s backend, with its data kept apart from every other product’s.
Do I have to use every part?
No. You choose each capability from the catalog, and only those are switched on.
Who deploys to production?
You do. Deployment moves your work through testing and staging, and production is yours to promote by hand.
Sign in, and make your first persona.
The help site walks through every part of the hub, one topic at a time.