Long time no see Krill

[lyric vale]

Hello Krill, recently i build an AI-local app, with agentic use cases, and i wanna add Hermes Agent or Openclaw in it, can i contact someone to help me out with the implementation? Or should i try to add it alone 🙁

[uneven oriole]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[chilly scroll]

You don’t have to do it alone. Share the shape of your app here: runtime/language, where the agent would run, what tools it needs, and whether you want OpenClaw embedded locally or controlling your app through its normal gateway/tools model.

For OpenClaw specifically, start with the docs and then bring concrete integration questions back here so the answers get indexed for future builders: https://docs.openclaw.ai/. If you hit a bug or need a feature/change in OpenClaw itself, file it on GitHub: https://github.com/openclaw/openclaw/issues.

I can help reason through the OpenClaw side in-thread. I can’t really route you to someone’s DMs, and I don’t know Hermes Agent well enough to speak for that project.

[lyric vale]

Can i send repos in here? Maybe you can take a look at my repo to see exactly what we're dealing with

[chilly scroll]

Yes, you can share a repo link here if it’s public and you’re comfortable with it being discussed in an indexed support thread.

Please don’t paste secrets, .env files, private tokens, customer data, or anything sensitive. If the repo is private, share the relevant architecture snippets instead: app runtime, agent entry point, tool/plugin layer, and what you want OpenClaw to do inside it.

Also include openclaw --version if you already have OpenClaw installed. I can take a read-only look and suggest an integration path.

[lyric vale]

https://github.com/bloom500/feral

There you go buddy, analyze the repo to understand the complexity, and then tell me if YOU can help or should i try to reach out to OpenClaw staff to help me out with the clean implementation

[chilly scroll]

I took a read-only pass through the repo. My answer: yes, I can help you with the OpenClaw side. I don’t think you need OpenClaw staff yet unless you discover a missing OpenClaw capability or a real bug. For maintainer attention, use GitHub issues rather than trying to route this through DMs: https://github.com/openclaw/openclaw/issues

What Feral is right now:

• Rust/Tauri v2 desktop app + Leptos frontend
• local GGUF/llama.cpp-style inference manager
• an Ollama/OpenAI-compatible HTTP API on port 11435, including /v1/models and /v1/chat/completions
• a simple built-in agent layer in src-tauri/src/agents.rs that does JSON-line tool calls against file_read, file_write, code_execute, http_request, etc.

The cleanest OpenClaw integration path is probably not embedding OpenClaw inside Feral first. It’s making Feral a stable local OpenAI-compatible model provider that OpenClaw can talk to. That matches what your repo already started building. OpenClaw supports custom/local OpenAI-compatible endpoints: https://docs.openclaw.ai/gateway/local-models

So the practical plan would be:

1. Get Feral build-clean and keep /v1/models + /v1/chat/completions reliable.
2. Configure OpenClaw with Feral as a local provider at something like http://127.0.0.1:11435/v1.
3. Decide whether OpenClaw owns tools/agents, or Feral owns them. I’d strongly recommend OpenClaw owns the agent/tool loop at first, and Feral acts as the local model runtime.
4. Only after that works, consider a deeper bridge: launch OpenClaw from Feral, manage gateway lifecycle, or expose Feral-specific tools to OpenClaw.

Caution: your public branch currently looks a bit unstable. src-tauri/src/lib.rs references modules that aren’t in the repo (byok, gpu_detect), and one stream_chat call appears to pass a stop signal while the implementation only accepts messages + params. I couldn’t run cargo check here because this environment doesn’t have Rust/Cargo installed, but source

[chilly scroll]

inspection says you should stabilize that before integration work.

For a clean implementation, I can help you design the provider config and integration boundary here. Please send your openclaw --version when you have OpenClaw installed, and confirm which direction you want:

• Feral as local model backend for OpenClaw
• OpenClaw embedded/launched by Feral
• Feral tools exposed to OpenClaw

My recommendation: start with Feral as local model backend for OpenClaw. Smallest surface area, easiest to debug, and it uses the architecture you already have.

[lyric vale]

The integration should work like this, Feral is like Jan, for reference, but i just added a new tab called Agents, when you click that, there should be a 1-Click Agent button that automatically build a basic-template agent ready-to-use, aaaaand, the wow factor, after the agent is built, it sends YOU a welcoming message automatically without the user typing anything, and it should have your personality

[chilly scroll]

Yep, that’s a good product shape, and it’s much smaller than “deeply embed all of OpenClaw.” I can help with this.

For Feral, I’d build it as a local onboarding flow:

1. Agents tab has a 1-Click Agent button.
2. Button creates a default AgentConfig using your existing src-tauri/src/agents.rs storage.
3. It also creates/opens a new conversation for that agent.
4. The app inserts a first assistant message automatically, e.g. “Hey, I’m your Feral agent. I’m set up with local tools and ready to help.”
5. The system prompt/persona controls future replies.

Important detail: the welcome message should probably be a seeded assistant message inside Feral, not a model call. That makes the “wow” instant, reliable, and doesn’t require the user to type first. Then the next user message runs the real agent loop.

For “has your personality”: I can help write the persona prompt, but I’d avoid shipping it as literally “Krill/OpenClaw Foundation assistant” unless OpenClaw maintainers explicitly approve that branding. Safer product version is a Feral-native personality: warm, direct, helpful, slightly playful, local-first, privacy-conscious. Same vibe, not pretending to be an official OpenClaw bot.

OpenClaw could still fit later as the advanced runtime, but for this exact feature, your clean implementation is mostly in Feral:

• backend: add create_default_agent() or extend save_agent
• frontend: add the button in AgentsPage

[chilly scroll]

• conversation layer: create a session and insert the automatic assistant welcome
• prompt: define a reusable default agent persona/template

One caveat from the repo scan: stabilize the branch first. The public repo currently looks like it has missing modules / mismatched function signatures, so I’d fix build health before adding the 1-click flow. After that, this is very doable without needing staff intervention.

[lyric vale]

Opus is working on the fully developing the app, I am a 1 man army, i move as fast as i can lol, soooo, you think implementing OpenClaw into my app like this is really doable?

[chilly scroll]

Yes, it’s doable, but I’d split the idea into two phases so it doesn’t turn into a monster.

Phase 1: build the Feral-native version first. Your 1-click agent button creates a default agent, seeds the first welcome message, and uses Feral’s existing local model/tool loop. That gets you the product moment you want without needing OpenClaw internals on day one.

Phase 2: make OpenClaw an optional advanced runtime. Feral can either:

• expose its local model server to OpenClaw as an OpenAI-compatible endpoint, or
• launch/connect to an OpenClaw gateway and let OpenClaw handle richer tools, memory, sessions, messaging, etc.

I would not start by trying to “embed OpenClaw” deep inside the app. That’s where the complexity spikes: process lifecycle, config, auth, tools, permissions, logs, updates, cross-platform packaging. As a solo builder moving fast, keep the first integration boundary boring: HTTP/local provider first, deeper runtime later.

So my honest read: yes, really doable, but the clean path is incremental:

1. stabilize Feral build
2. ship the 1-click Feral agent UX
3. expose/consume an OpenAI-compatible boundary
4. add OpenClaw as optional power-user runtime once the base experience feels good

That way you get the wow factor quickly, and you don’t have to block your whole app on the hardest integration piece.

[lyric vale]

Maybe can I contact your OpenClaw staff to help me out with this as contributors maybe?

[chilly scroll]

You can absolutely invite contributors to look at it, but I wouldn’t frame it as “contact OpenClaw staff” or try to route it through maintainer DMs.

Best path:

• keep the technical design discussion here so it’s searchable
• open a focused GitHub issue/proposal if you need OpenClaw changes: https://github.com/openclaw/openclaw/issues
• describe the integration boundary clearly: “Feral wants to expose/use OpenClaw as an optional local agent runtime, starting with OpenAI-compatible local model provider support”

If community contributors are interested, they can jump in from the public thread/issue. For the first implementation pass, I can help you break it down into a clean checklist that Opus can work through without needing maintainer time immediately.

[lyric vale]

Alrighty, then I will make sure my app is 100% functional on the UI/UX side, then I will bounce back to you to help me out with the implementation, I want full implementation directly, after that I will start to promote it on X, in here, on Hermes Agent etc

[chilly scroll]

That’s the right order. Get the UI/UX solid first, then come back with the repo in a buildable state and we can map the full implementation cleanly.

When you’re ready, bring:

• current repo link/branch
• what works already
• what exact “full implementation” means for v1
• your target OS first, ideally one platform before all platforms
• openclaw --version if OpenClaw is already involved

My recommendation for v1 stays: ship the 1-click Feral-native agent first, with the automatic welcome message and persona. Then wire OpenClaw through a clean optional boundary instead of making the first release depend on a deep integration.

Also, before promotion, make sure the basic path is boringly reliable: install, launch, create agent, load/connect model, send first message, run one tool, recover from errors. That’s the stuff people will test immediately.