Open roadmap
Help us build what comes next.
An evolving map of what Nautilo is working toward, what is open, and where experienced open-source contributors can make a real difference.
HOW TO USE THIS MAPFind the territory that matches your experience. Read the brief. Tell us where you can help.
The work ahead
There’s a hell of a lot left to build.
Some of it is already moving. Some is open and ready to shape. Some needs research before anybody should write code. This is our evolving map of where Nautilo is headed—and where your experience could move it forward.
Find your territory
What’s your expertise?
Search the work ahead or choose a field. Some areas are ready to shape now. Others need research or another experienced hand alongside the people already moving them forward.
6 directions shown
Integrations
Third-party integrations that belong in the system
People and their Genies can act through the services they depend on without surrendering the Nautilo trust model.
We could use
What would help now
A grounded integration contract and one complete provider path that proves ownership, permissions, recovery, and long-term maintainability.
Read the full brief
- Why now
- Useful intelligence must reach the tools where life and work already happen—but a thousand shallow connectors would recreate the old app mess.
- Current state
- Nautilo can control selected services, but there is no finished public integration contract or broad catalog.
- Desired outcome
- A repeatable contract for integrations that remain understandable, recoverable, and maintainable after the demo.
- Working with
- Integration and trust-boundary maintainers
Constraints
- Fit Nautilo’s Connection, Capability, approval, Room, Namespace, and Agent model.
- Define identity, data movement, secrets, destructive actions, retries, and revocation.
- Prove failure behavior without committing live credentials to tests or logs.
Not the goal
- A generated API client with no product contract.
- A brittle one-off demo that bypasses ownership, approvals, or recovery.
Useful evidence
- Provider/API research with code and protocol citations.
- Connection ownership, permission, secret-lifecycle, and data-boundary decisions.
- Failure matrix, UX states, contract tests, and a named stewardship plan.
Long-term stewardship: The proposal must name who will track provider changes, compatibility, examples, and release verification.
Local AI
Local models on user-owned hardware
Operators can choose user-owned inference without losing a usable Nautilo experience.
We could use
What would help now
Measured runtime and hardware research that identifies the smallest supportable local-model path.
Read the full brief
- Why now
- Self-sovereignty gets stronger when the model path can live inside the operator’s own boundary, not only behind someone else’s API.
- Current state
- Deployments can choose model providers, but a supported user-owned local inference path is not release-ready.
- Desired outcome
- A smallest coherent path for running supported open models on hardware the operator controls.
- Working with
- Model runtime and operator-experience maintainers
Constraints
- Start from the current provider/runtime architecture instead of inventing a parallel agent stack.
- Keep model capability, hardware limits, privacy posture, and fallback behavior legible to the operator.
Not the goal
- Claiming every model or accelerator works.
- Hiding degraded capabilities behind a generic private-model badge.
Useful evidence
- Current architecture map and measured hardware/runtime experiments.
- Capability and fallback matrix for the proposed model path.
- Operator setup, diagnosis, upgrade, and removal story.
Long-term stewardship: The proposal must define supported runtimes and how compatibility claims expire.
Infrastructure
Deployment, resilience, and recovery
Operators can deploy and recover Nautilo with fewer bespoke rituals and fewer silent failure states.
We could use
What would help now
A complete deployment and recovery path that makes upgrades, rollback, state ownership, and failure behavior boring and explicit.
Read the full brief
- Why now
- The platform is already powerful; the operator path should become boring, repeatable, and survivable.
- Current state
- Single-server Compose and the launch deployment path are the grounded baseline; broad HA, blue/green, and cloud-driver support are not finished.
- Desired outcome
- Additional deployment and resilience paths with explicit state ownership, recovery, observability, and upgrade proof.
- Working with
- Deployment and operations maintainers
Constraints
- Preserve a reliable single-server path while expanding deployment choices.
- Separate application rollback, database recovery, object recovery, and disaster recovery.
- Make repeated runs convergent and cleanup bounded.
Not the goal
- A pile of cloud templates with no supported operating contract.
- Calling an image rollback a database recovery strategy.
Useful evidence
- A complete deploy, upgrade, failure, rollback, restore, and cleanup demonstration.
- State inventory and idempotency proof.
- Cost, limits, observability, security, and ownership boundaries.
Long-term stewardship: A supported driver needs an owner for provider drift, test coverage, and release verification.
Federation
Federation between private Servers
Private Nautilo circles can collaborate without surrendering their separate rules, keys, and ownership.
We could use
What would help now
Threat modeling and a smallest testable protocol experiment—not a full implementation yet.
Read the full brief
- Why now
- Separate trusted circles should eventually connect by choice, without recreating one giant backend that can see everything.
- Current state
- Nautilo does not have a shipped federation contract between private Servers.
- Desired outcome
- A threat-aware product and protocol shape for consented collaboration across independently operated Servers.
- Working with
- Architecture, identity, and security maintainers
Constraints
- Begin with threat model, identity, routing, consistency, discovery, and recovery—not transport alone.
- Preserve the autonomy and trust boundary of every private Server.
Not the goal
- Relabeling relay behavior as federation.
- Turning private Servers into one central surveillance domain.
Useful evidence
- Threat model and trust-boundary map.
- Identity, consent, routing, failure, revocation, and recovery semantics.
- Smallest testable protocol experiment with explicit non-goals.
Long-term stewardship: Protocol work requires long-lived security and compatibility ownership.
Mobile
Mobile as a first-class place to live and work
People and machine people remain present and useful when the user leaves the desktop.
We could use
What would help now
Experienced help with mobile interaction states, platform behavior, testing, and the path to a first-class release.
Read the full brief
- Why now
- A lifelong interface cannot stop existing when someone closes a laptop.
- Current state
- Mobile is active release work; public support and exact capability parity remain in progress.
- Desired outcome
- A coherent mobile Nautilo experience that belongs to the same system rather than a thin companion app.
- Working with
- Mobile product and design maintainers
Constraints
- Work inside the approved cross-platform product direction.
- Show lifecycle, offline, denied, disconnected, narrow-screen, accessibility, and recovery states.
- Do not let a mobile shell silently redefine core entities or permissions.
Not the goal
- An unsolicited parallel mobile architecture.
- Pixel mockups without interaction, data, permission, and recovery states.
Useful evidence
- User journey and state-transition map.
- Responsive interaction evidence and accessibility behavior.
- Grounded implementation seams and release-candidate proof.
Long-term stewardship: Mobile changes remain jointly shaped by the mobile product and design owners.
Interface
Interface and design stewardship
The interface becomes more powerful and legible without becoming generic, fragmented, or designed by committee.
We could use
What would help now
An exceptional product designer or frontend builder who wants to help evolve a rich interface as a coherent system.
Read the full brief
- Why now
- The richer Nautilo becomes, the easier it is for disconnected improvements to turn into a product nobody can hold in their head.
- Current state
- Nautilo has a broad desktop surface and an emerging design language; it needs strong stewardship, not committee pixels.
- Desired outcome
- A small, accountable stewardship group can evolve Nautilo’s interface without sanding away its personality or coherence.
- Working with
- Product and interaction-design maintainers
Constraints
- Preserve one coherent visual and interaction language across the rich frontend.
- Show journeys, states, keyboard behavior, accessibility, narrow layouts, and reduced motion before implementation.
- Reuse or deliberately evolve the design system; do not smuggle in a new one page by page.
Not the goal
- Drive-by redesigns generated from generic component libraries.
- Major UI implementation before the interaction is inspectable.
Useful evidence
- Journey, interaction states, ASCII or visual wireframes, and responsive behavior.
- Accessibility, focus, keyboard, and reduced-motion decisions.
- Component/system impact and a realistic prototype when spatial behavior matters.
Long-term stewardship: Direction belongs to named product and design stewards, with focused contributor collaboration.