This page will show what we are building now, what comes next and what we are considering later, across every module and every part of the platform. No items are published yet. Everything else is here already: the lanes, the areas, the rules for how items move and the principles that decide them.
Put admission in front of your MCP servers, repositories, SaaS tools and cloud accounts. Every agent gets a lease or a reason – and you keep the lever to stop any of them.
© 2026 Intramedial. All rights reserved. Intramedial is a product by Trustvice. Secured and supercharged by Avonao Labs.
Report abuseFour lanes, from the work in progress to the work released. Each item will sit in exactly one lane and carry the area it belongs to, so you can follow one module or one part of the platform. The board is empty until the founder publishes the first items.
Showing items in all areas: none published yet.
Being built. Work has started and the item is on its way to the changelog.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Decided and queued. It is the next work to start once the current items ship.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Worth doing and kept in view, but not yet scheduled. The scope can still change.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Join the waitlist →Released. Each shipped item links to its changelog entry and its documentation.
Items appear here when the roadmap opens
No items have been published in this lane yet.
Read the changelog →Every card on the board will carry the same six parts, so an item says what it is, where it stands and where to read more, and nothing more than that.
The roadmap follows the shape of the product. Module areas are the eight groups of the catalogue; platform areas are the parts every module shares. Each area links to what exists in it today.
One area per catalogue category. New modules and changes to existing ones land here.
Who each agent is, who it answers to, what it sees.
Items: 0Modules today: 6Who may touch a shared resource, and for how long.
Items: 0Modules today: 7The rules agents run under, written down as code.
Items: 0Modules today: 6Where the plane stands between an agent and the world.
Items: 0Modules today: 6Collisions found before they turn into outages.
Items: 0Modules today: 6How a conflict between agents ends, and who decided.
Items: 0Modules today: 6Neutral ground where agents meet, deal and work.
Items: 0Modules today: 9What happened, who did it, and how to put it back.
Items: 0The surfaces and guarantees that every module relies on.
The versioned REST API, the MCP server and the actions an agent can call.
The ledger bundle format, the published key and every way to verify a bundle without us.
An item enters the board when we decide it is worth doing, and moves one lane at a time. Lanes describe the stage of the work. They are not dates, and the roadmap does not promise when an item ships.
Public plan
/changelogSome requests will not fit the product: for example a feature that would make a ledger claim more than it can show. We will say so plainly, with the reason, rather than leave the request open.
What a bundle cannot prove →The same rules that shape the product decide its roadmap. A request that breaks one of them does not ship in that form, however often it is asked for. Each rule links to where the product already keeps it.
A new module or field has to say exactly what it shows and what it does not. If an entry would imply a fact we did not observe, the design changes until it does not.
Where it holds todayWhat a bundle cannot prove →02We take no side in the record. We sign what we observe or what you report, label which is which, and never add a verdict.
Where it holds todayObserved and reported facts →03Anything new must stay checkable offline with a published key, with no account and no call to our servers.
Where it holds todayVerify in your own code →04Changes within a version are meant to be additive. Key rotation should be too, so a bundle signed today still verifies after a new key arrives.
Where it holds todayRotation and old bundles →05We prefer designs that need a hash over designs that need your content. A feature that would make us store more data has to earn it.
Where it holds todayData and privacy →06Every release states its known limits next to what it adds. The roadmap will do the same for what is planned.
Where it holds todayKnown limits today →The changelog is the record of what is real today. No Intramedial release is listed in it yet, so none is shown here. Once the roadmap opens, every item in Shipped will point to one of its entries.
Until the roadmap opens, the changelog's list of known limits is the most direct statement of what is not finished yet. Read the known limits →
You can ask for a module, a field, an integration or a change today. Requests sent now will be the first input to the roadmap when it opens.
The general contact form, for a new module, a missing field or a change to an existing one.
Open/contact?topic=general →If you already use Intramedial and something is missing in your work, support can record it with the details.
Open/support →For a platform, framework or service you want Intramedial to work with.
Open/contact?topic=integration →A vulnerability is not a feature request. Report it privately through the security page instead.
Open/security/report →There is no voting yet. When the roadmap opens, you will be able to add your vote to an item instead of writing a new request. Until then, a message to us counts.
Join the roadmap list and we will email you when the first items are published, and when the roadmap changes after that. It is one list with one topic, and you can leave it at any time.
Where ledger data is stored and signed. 4 zones today, one chosen per workspace.
/docs/data-regionsWorkspaces, fleet map, agents, exports, team, API keys and billing, in one place.
/docs/dashboardVerifier libraries, the command line and the tools Intramedial is meant to work with.
Signing keys, authentication, tenancy isolation, outbound request controls and abuse controls.