Omnigent Roadmap Discussion

[dbczumar]

We'd love your input and suggestions for the Omnigent roadmap. Please share your ideas and requests here - we're excited to discuss them!

(cc @dhruv0811 @fanzeyi @aravind-segu @serena-ruan @TomeHirata @PattaraS @daniellok-db @bbqiu @Edwinhe03 @shivam5 @sabhya-db @hzub @ckcuslife-source @mateiz)

[talhasifkhan]

The current support for different models is great, but being able to use other subscriptions besdies Claude and ChatGPT would be nice, namely Gemini/Antigravity.

[jkfnc]

Thanks, There are so many

1. Voice Mode to use browsers built-in STT for using voice
2. Canvas mode to use HTML or react canvas like cursor on right pane Cursor Canvas
3. Tasks/Work Items below Inbox on Left Pane, where we can push tasks via websockets or via Omnigent MCP ex: A slack message, email or github/jira issue can become a task and tasks can be linked to be processed by agents and it can show plan and work on it, but maintain its history. like subsessions within a session or like threads in slack. This can be Humans Todo list for the day ,
4. Common MCPs , Skills, Policies that can be shared across sessions and different agents.
5. Secret management - Lets say i share a common session with colleague. When they do git commit or aws cli actions it should use their own individual creds based on who signed in with oauth and not mine.
6. Scheduled tasks - do weekly report on Friday night.
7. Shortcut in WebUI to jump across sessions like Ctrl+1, Ctrl+2.
8. Push notification support for mobile.
9. Support for lightweight install like omnigent[claude] omnigent[codex]
10. Usage tracker for all connected agents on home page claude: 10% of 5 hour/50% of weekly, Codex 20% of 5 hour/56% of weekly.
11. Tokenmaxx mode - Pickup work from Todolist and get to 90% limit on all subscriptions like Claude/Cursor/Codex/Gemini during off hours.
12. Additional omnigent tools like below

Loops/Monitor
create_loop	Cron-scheduled recurring prompts
create_monitor	Stream a command; fire a prompt per line
list_schedules	List loops & monitors
delete_schedule	Delete a loop or monitor

Work items
create_work_item	Create task item (idempotent by dedup_key)
list_tasks		List tasks / work items
update_work_item	Update status, PR URL, needs_review

[yang-seen]

A few items:

1. Mermaid supported markdown editor. Notion has a great implementation that lets you view code and diagram, just the diagram or just the code.
2. Better recovery so that if an auth token expires we don't get into a pretty broken state and have to manually resume every single subagent session to recover the running state but instead just do this automatically After Restarting the host
3. slack as a client. This may require sandboxes for collaborative use cases. things may get a bit more complicated if using Local hosts. Omnigent would have to resolve the Slack user to their corresponding account and then use their hosts if it's available. If multiple people reply to the same threads then share the thread implicitly or explicitly after asking for permission
4. Enhance worktree support with One-click checkbox to auto-generate worktree name and default to branch of main, add hooks to customize behavior

[andrewreid]

I’ve written in #1352 about what I reckon a centralised MCP configuration/management could look like.

I haven’t written about it yet, but I’d love for Omnigent to expose an MCP tool that allowed a session to register a GitHub issue or PR as something to “follow”, and then the server would poll via the Notifications API at a configurable interval for changes to that item/PR. The server could then deliver that to the session that registered the follow request so it could take action.

Use case: I open a PR via an Omnigent session, and if feedback is left, I’d like that session to take action on it.

[gastronimo]

Introduce a minimal execution backend extension point.

While reviewing the terminal architecture, I noticed TerminalRegistry is already nicely decoupled, but create_terminal_instance() currently combines execution environment preparation with tmux-specific session realization.
Would you be willing to expose a small stable extension point that allows external execution providers while keeping tmux as the default?
I’m only proposing a cleaner separation of responsibilities.
One motivation is experimenting with advanced alternative execution substrates such as Herdr.

Problem: Terminal execution is currently coupled to tmux.
• Observation: TerminalRegistry is already backend-agnostic.
• Proposal: Separate environment preparation from session realization via a backend hook.
• Compatibility: No behavioral changes; tmux remains the default.
• Motivation: Enable external execution providers without increasing maintenance burden for Omnigent.

Today create_terminal_instance() does roughly:
Prepare execution environment
+
Realize execution session (tmux)
Those are two different responsibilities.
Separating them has benefits for possible plugins

Enhancement: Introduce Execution Backend Hook for Pluggable Execution Backends
Scope:
• Zero behavioral changes.
• tmux remains default.
• No API breakage.
• External packages can register alternate execution providers.
• Existing tests continue to pass.

Thank you in advance!

After learning more about Omnigent's Platform/Worker architecture, I think the broader architectural opportunity isn't Herdr specifically, but a pluggable local execution/session backend for authenticated workers. Herdr is one candidate implementation, but the abstraction could also support tmux, systemd, containers, or other host-local process managers.