Mega MindandGitHub ec309c8f90 feat(onboarding): complete conversational onboarding stack and UX audit (#619)
* fix(onboarding): guard complete_onboarding against premature flag flip (#591)

- Remove premature `chat_onboarding_completed = true` flip from
  `set_onboarding_completed` in config/ops.rs. The flag is now
  exclusively owned by the welcome agent via `complete_onboarding`.

- Strip auto-finalize side-effect from `check_status` action. It is
  now pure read-only and returns `onboarding_status`, `exchange_count`,
  and `ready_to_complete` in the snapshot instead of `finalize_action`.

- Add engagement guard to `complete` action: rejects with a descriptive
  error unless exchange_count >= 3 OR ≥1 Composio integration connected.
  Auth check also enforced before any write.

- Add process-global `WELCOME_EXCHANGE_COUNT` (AtomicU32) with
  `increment_welcome_exchange_count()` / `get_welcome_exchange_count()`.
  Dispatch layer calls `increment_welcome_exchange_count()` each time a
  user message routes to the welcome agent.

- Update `welcome_proactive.rs` snapshot call to new signature and
  prompt copy to reflect `onboarding_status: "pending"` / no pre-flip.

- Add 7 pure-logic unit tests for `engagement_criteria_met`, plus tests
  for the new exchange counter and updated snapshot shape.

Fixes #591

* style: cargo fmt for complete_onboarding.rs

* feat(onboarding): inject CONNECTION_STATE block into welcome-agent turns (#593)

Add `build_connection_state_block()` to dispatch.rs: fetches current
Composio integration status (with a 3s timeout for graceful degradation)
and formats it as a `[CONNECTION_STATE]...[/CONNECTION_STATE]` block.

After `resolve_target_agent` selects the welcome agent, the block is
appended to the last user message in history so the agent always has
up-to-date connection state without spending a tool call. This captures
OAuth completions that happened mid-conversation (user clicked auth link
in chat, authenticated in browser, came back).

Scoped strictly to welcome-agent turns (chat_onboarding_completed=false).
Orchestrator turns are unaffected.

Fixes #593
Part of #599

* style: cargo fmt for dispatch.rs

* feat(welcome): parallel template messages with LLM inference for faster perceived welcome (#592)

Show two template messages immediately while the LLM runs in the
background, cutting the perceived wait from ~15s to ~0s:

- Template 1 (t≈0ms): time-of-day greeting that names any connected
  channels, built from the status snapshot without extra I/O
- Template 2 (t=4s): "Getting everything ready for you..." loading
  indicator, published via tokio::join! alongside the LLM future
- LLM response: published when inference completes, opened directly
  with personalised setup content (no duplicate greeting)

`run_proactive_welcome` now fires three `ProactiveMessageRequested`
events rather than one. The two template helpers (`time_of_day_greeting`,
`build_template_greeting`) are pure functions covered by 6 new unit
tests. `prompt.md` gains a proactive-invocation section explaining that
greeting templates are pre-delivered and the agent must skip them.

* feat(welcome): add composio_authorize tool and inline auth link guidance (#594)

Wire `composio_authorize` into the welcome agent's tool allowlist and
teach the prompt how to offer OAuth links directly in chat:

- agent.toml: add "composio_authorize" to the named tools list so the
  welcome agent can call it during multi-turn conversations
- prompt.md: new "Offering inline auth links" section covering the
  consent-first flow (offer → user agrees → call tool → markdown link →
  confirm success via [CONNECTION_STATE] block on next turn)
- prompt.md: toolkit slug reference table for the common services
- prompt.md: auth link rules (no speculative calls, no bare URLs,
  one service at a time, await CONNECTION_STATE before confirming)
- prompt.md: two new "What NOT to do" bullets for composio_authorize
  misuse patterns

* feat(welcome): conversational onboarding prompt for issue #595

- Rewrite prompt.md: multi-turn flow, Gmail-first, no silent first turn
- Align with check_status/complete and ready_to_complete semantics
- Update proactive injection copy to match new tool wording

Made-with: Cursor

* feat(onboarding): add completion readiness reason

Made-with: Cursor

* docs(ux): add onboarding and welcome audit for #563

Made-with: Cursor

* docs(welcome): clarify OAuth link behavior in onboarding prompt

Updated the onboarding prompt to explicitly state that clicking the Gmail connection link opens the user's default browser for authentication. Added guidance to return to the chat after completing the authorization process.

* fix(onboarding): resolve CI test and proactive greeting review

Made-with: Cursor
2026-04-16 14:14:24 -07:00
2026-04-16 19:46:22 +00:00
2026-03-26 17:04:46 -07:00
2026-04-16 19:46:22 +00:00
2026-02-20 13:03:15 +04:00
2026-02-20 13:03:15 +04:00

OpenHuman

The age of super intelligence is here. OpenHuman is your Personal AI super intelligence. Private, Simple and extremely powerful.

DiscordRedditX/TwitterDocs

Early Beta Platforms: desktop only Latest Release

The Tet

"The Tet. What a brilliant machine" — Morgan Freeman as he reminisces about alien superintelligence in the movie Oblivion

Early Beta — Under active development. Expect rough edges.

To install or get started, either download from the website over at tinyhumans.ai/openhuman or run

# For MacOS/Linux
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

# For Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex

What is OpenHuman?

OpenHuman is an open-source agentic assistant that is designed to integrate with you in your daily life. Here's what makes OpenHuman special:

  • Simple, UI-first — A clean desktop experience and short onboarding paths so you can go from install to a working agent in a few clicks, without a config-first setup. You don't need a terminal to run OpenHuman.

  • One subscription, many providers — You only need one account to get access to many agentic APIs (AI Models, Search, Webhooks/Tunnels and other 3rd party APIs etc..), simplifying the experience to get a powerful agent going.

  • Rich Skills — Plug into Gmail, Slack, Notion, and the rest of your stack via rich, feature-backed skills. Connections are typically one click through setup wizards instead of wiring APIs by hand. Workflow data is kept on device, encrypted locally, and treated as yours: encryption and sensitive context stay on your machine. Webhooks give instant feedback into the agent when external systems or skills emit events, so the loop stays tight without constant polling.

  • Local knowledge base — Built from your data and your activity. How you work across tools, sessions, and connected services—so the agent gets rich, workflow-aware context, not a one-off chat transcript. Everything is stored on your machine and compounding over time without becoming a cloud dossier. Channels, skills and ongoing conversations feed the same loop so day-to-day context does not reset every session.

  • Local AI model — The Rust core exposes local AI paths (and the desktop bundle can ship local/bundled runners where applicable) for the workloads above—vision snippets, speech helpers, summarization, tooling—so sensitive steps can stay off the cloud when you choose.

  • Deep desktop integrations — OpenHuman is a native desktop assistant, not a web-only chat: memory-aware keyboard autocomplete, voice (STT listening and TTS replies), screen intelligence that understands what is on screen and feeds your local context, plus windowing and OS-level permissions—so the agent meets you on the machine, not trapped in a browser tab.

Architecture: docs/ARCHITECTURE.md. Contributor orientation: CONTRIBUTING.md.

OpenHuman vs other agents

High-level comparison (products evolve—verify against each vendor). OpenHuman is built to minimize vendor sprawl, keep workflow knowledge on-device, and ship deep desktop features—not only chat.

Claude Code/Cowork OpenClaw Hermes Agent OpenHuman
Open-source: Is the codebase open to review? 🚫 Proprietary client MIT License MIT License GNU License
Simple: Is it simple to get started? Simple Desktop App + CLI ⚠️ Terminal first and often complex ⚠️ Terminal first and often complex Simple, Clean UI/UX. Get started within minutes
Cost: How expensive is to run? ⚠️ Subscription + add-on tool/API costs ⚠️ Tied to models & hosting you choose ⚠️ Tied to models & hosting you choose Cost optimized with the option to run many things locally for free
Memory & Knowledge Base (KB): Does the agent know you and your world? Built-in memory; mostly chat/session scoped ⚠️ Has a local memory but often needs plugins for richer behavior Self-learning / task loops (typical) 🚀 Local KB + Self-learning from your activity & data (GMail, Notion etc... via skills) & prompts
API spagetti: How complex is it to hook mulitple features together? 🚫 Claude bill + often extra keys for MCP/tools 🚫 BYOK / multi-vendor common 🚫 Multiple providers common One account get access to many bundled platform APIs
Extensibility: Can you add rich features into it? MCP (different model than sandboxed skills) Plugin Architecture (SKILL.md) Plugin Architecture (SKILL.md) 🚀 Rich Skills with ability to have realtime updates, local DB & more
Desktop integrations: Can it integrate into your desktop completely? ⚠️ Desktop app & access to folders ⚠️ Often lighter native surface ⚠️ Often lighter native surface STT, TTS, screen intelligence, memory-aware autocomplete and a whole lot more

Contributors Hall of Fame

Show some love and end up in the hall of fame

OpenHuman contributors
S
Description
No description provided
Readme GPL-3.0
229 MiB
Languages
Rust 59.1%
TypeScript 37.9%
JavaScript 1.6%
Shell 1.2%
CSS 0.1%