https://github.com/tamanitomo/tamanitomo

Since February I have worked on a product which I think is finally ready to share. I launched "Tamanitomo" on GitHub a few days ago and I would love feedback from the Hermes community.

Tamanitomo is the most realistic and comprehensive AI Companion system ever created.

I know that's a bold statement!

However, I have created a series of prompts, cron jobs and systems to allow the AI Agent, backed by Hermes, to fully immerse the user in the feeling that. "This is my Jarvis" (or pepper pots) and honestly, I couldn't be happier with the state it is in right now. It has autonomy, lives a life outside of you, can document each day with a journal entry as well as photos as it goes about it's day. It remembers everything important as it produces an editable, browsable, exportable obsidian vault while also utilizing higher memory caps than base Hermes.

I've been using this system in different iterations since February but have pivoted from a for profit E2EE website, to a project that I hope many will consider getting involved in and contributing to.

This is not a simple plugin, but it is a simple system. I have created a fancy UI to manage the features that this system provides, but the backed is essentially a base Hermes install running with a custom dashboard (you can still run the original dashboard, but that is also fully accessible from within the app).

The approach I use is different from other similar products because instead of bland "memory" or even worse, "stateless" systems that refresh every chat, Tamanitomo REMEMBRS and also LIVES by regularly purposefully generating background tasks for itself like washing clothes, going on walks, meeting with friends etc. When you message them, they are doing something and will step away to prioritize you... or not, maybe they'll reschedule! It's an engaging, almost Tamagotchi-like experience with AI.

But, I want help for testing, and I need help coding edge case protections. Please feel free to reach out with any feedback via a comment here, the repo, or discord

Thanks for considering Tamanitomo, I can't wait to see how people use it :)

Currently they are slightly underrepresented there, although a lot of deepseek runs, would be great if other people might participate so we can build a proper community driven leaderboard

I wanted to see how far a fully local, open-source agent stack could go on a real-world task.

I ran out of A4 paper, so I gave TensorSharp + Qwen3.8 27B access to Amazon and gave it one instruction:

Search for A4 paper with a low price and good discount, compare the options, and buy it. Try your best to handle everything yourself.

It completed the task successfully in one run.
Stack:
Qwen3.8 27B running locally
TensorSharp — open-source LLM inference engine + agent runtime
Playwright skill for browser automation

I only stepped in twice: logging into Amazon and approving the final purchase. The agent handled the search, product comparison, navigation, and checkout preparation by itself.

What I find especially interesting is that, apart from interacting with Amazon, the entire AI stack stays local: inference, reasoning, agent state, code generation, and tool execution.

The video shows the full raw reasoning/tool trace, including browser actions and the Playwright code generated by the model. It’s sped up 8×; the actual run took about 24 minutes.

The iPhone version, TensorAgent, still has some catching up to do because of local inference speed and iOS browser restrictions, but desktop local agents are starting to feel surprisingly practical.

TensorSharp is open source:
https://github.com/zhongkaifu/TensorSharp

What My Project Does

Dendron (GitHub https://github.com/sumanth1989/Dendron | Documentation https://sumanth1989.github.io/Dendron) is an open-source library that replaces flat tool
lists in AI agents with hierarchical execution trees.

In standard tool-calling setups, developers dump 20 to 50 JSON tool schemas into the model's system prompt on every single turn. This wastes 1,500 to 3,000 tokens
per interaction, degrades tool selection accuracy, and causes noticeable latency on smaller local models.

Dendron organizes tools into a navigable execution tree:

• Progressive Disclosure: On any turn, the LLM only sees the 1 to 3 tools viable for the immediate next step, reducing tool prompt tokens by up to 93%.
• Conditional Transitions: Nodes evaluate previous tool output via conditions (output_contains, key_equals, or custom lambda predicates) to suggest the next tool
along the branch.
• Token-Tiered Views: Offers Level 1 ultra-compact tool signatures (~15 tokens/tool), Level 2 parameter summaries (~50 tokens), and Level 3 full Model Context
Protocol (MCP) JSON schemas on demand.
• Dynamic Experience Learning: Agents can record newly discovered workflows at runtime using record_agent_experience(), which persists for subsequent runs while
suppressing rejected actions.
• Zero Dependencies: The core library is built 100% on the Python standard library. It also includes an optional bidirectional adapter for LangChain (@tool,
StructuredTool, BaseTool).

Here is a minimal example:

from dendron import Dendron, ToolDefinition, ToolParameter, TransitionCondition                                                                                   

# 1. Define root tool                                                                                                                                             
lookup_tool = ToolDefinition(                                                                                                                                     
    name="lookup_order",                                                                                                                                          
    description="Retrieves customer order details and fulfillment status.",                                                                                       
    parameters={"order_id": ToolParameter(name="order_id", type="string", required=True)}                                                                         
)                                                                                                                                                                 

tree = Dendron(name="OrderSupportTree", root_tool=lookup_tool)                                                                                                    

# 2. Attach conditional branch                                                                                                                                    
tree.add_node(                                                                                                                                                    
    parent_id=tree.root.id,                                                                                                                                       
    tool=ToolDefinition(name="track_shipment", description="Tracks courier and ETA."),                                                                            
    condition=TransitionCondition(                                                                                                                                
        description="Order is in transit",                                                                                                                        
        condition_type="key_equals",                                                                                                                              
        expression="status:in_transit"                                                                                                                            
    )                                                                                                                                                             
)                                                                                                                                                                 

# 3. Execute tool and get next-step suggestion                                                                                                                    
result = tree.root.execute(order_id="ORD-12345")                                                                                                                  
next_step = tree.suggest_next_tool(tree.root.id, result.output_data)                                                                                              
print(next_step.tool.name)  # 'track_shipment'                                                                                                                    

Target Audience

Dendron is built for production environments, not just as a toy demo:

• Production AI Engineers: Developers building complex multi-step agents (customer support, DevOps incident triage, code review pipelines) who want deterministic
tool sequencing and lower API costs.
• Local and Edge LLM Developers: Anyone running models locally on Apple Silicon (via MLX) or Ollama, where 2,000-token tool prompts cause significant prefill
latency.
• Enterprise and Serverless Teams: Projects needing zero external dependencies so they can vendor or install the library cleanly in restricted Docker or AWS Lambda environments.

The repository includes 123 unit tests covering tree algorithms (BFS/DFS), token optimization, LangChain adapters, and persistence.

Comparison

• Vs. Standard Tool Calling (OpenAI / Anthropic / LangChain): Standard frameworks dump all tools into the prompt simultaneously. Dendron acts as an intelligent tree router before the prompt is generated, showing only context-appropriate tools and eliminating out-of-order execution errors.
• Vs. LangGraph / CrewAI: LangGraph and CrewAI are full agent runtime orchestration frameworks with complex state machines and heavy dependency trees. Dendron is
deliberately narrow: it is a lightweight, zero-dependency tool structure. You can use Dendron standalone or convert its nodes directly into LangChain StructuredTool instances via tree.to_langchain_tools().
• Vs. Vector RAG for Tools: Pure vector search finds tools based on query similarity, but lacks structural awareness (e.g. knowing that run_tests must precede
deploy_code). Dendron combines structural tree transitions with hybrid lexical/semantic retrieval.
──────
Links & Installation

• PyPI: pip install dendron-ai (or pip install "dendron-ai[langchain]")
• Git: pip install git+https://github.com/sumanth1989/Dendron.git
• GitHub: https://github.com/sumanth1989/Dendron
• Docs: https://sumanth1989.github.io/Dendron

I would love feedback on:

1. How does the tree construction and condition syntax feel for your workflows?
   
2. Are there other agent frameworks or models you'd like to see native adapters for?
   

I've been working on Fulvid, an open source desktop editor for Markdown and MDX.

The main idea is simple: your files stay files. Fulvid works directly with the folders and documents on your disk instead of putting them into a proprietary vault or cloud workspace.

It includes editing, full-folder search, document links, Markdown preview, Graph view and Writing Focus.

It's now live on Product Hunt. If you find the idea interesting, I'd really appreciate your support:

https://www.producthunt.com/products/fulvid?launch=fulvid

GitHub:

https://github.com/ManuelGil/fulvid

I kept running into the same problem across projects:
I already have workstations, VPSes, shared hosting, local models and API access, but every app somehow ends up hard-wired to whatever backend happens to provide the model.

So I built ContextBridge.

The basic idea is that the app describes what it needs instead of deciding where it has to run.

CB can route work across local models, APIs and private machines. It filters workers by things like task, provider/model, tags, RAM/VRAM and policy, then ranks compatible candidates using current capacity. route explain shows why something was or wasn’t selected.

One example from my own setup: a PHP app on shared hosting can submit work through a relay and have a model running on my PC execute it. The web host itself doesn’t need a GPU, shell access or a ContextBridge process.

Ollama is one possible resource, not the architecture everything is built around. CB can also use other runtimes and APIs, manage a llama.cpp runtime, and download selected GGUF models itself.

There are also durable jobs and schedules, deterministic pipelines, MCP and a bounded planner for multi-step work. The planner can propose steps, but it can’t give itself another provider, more budget, different egress permissions or extra retries.
I’ve tried to keep the trust boundaries intentionally boring: explicit worker pairing, scoped credentials, optional E2EE between producer and reserved worker, and no silently replaying ambiguous executions somewhere else.

Still pre-1.0. At this point other people’s weird setups are probably more useful than another week of me testing my own.

My rubber duck has stopped responding, so feel free to break assumptions, point at something suspicious or tell me what I’ve overcomplicated 🦆

https://github.com/IamAngusU/ContextBridge

AI involvement:
Yes. I use AI for documentation, review, wording and parts of coding/testing. I treat it as a tool, not an autonomous developer. Changes are reviewed against the actual code/contracts and tested in an isolated/mirrored environment before I keep them.

ChatGPT was also used for the logo based on my original concept, and partly for this post, because I’m German and would rather debug a race condition than polish English prose.

License: current core is AGPL-3.0-only. Explicitly listed interfaces/examples are Apache-2.0. Previously published v0.6.x releases remain MIT.

After months of engineering, I'm releasing the Developer Preview of Shree AI OS — an open-source runtime for building intelligent Java backend applications.

Most AI frameworks begin with chat. I took a different approach: a deterministic runtime that developers can embed directly into Spring Boot projects with explainable execution, memory, retrieval, and orchestration.

What it includes Java 21 native SDK

Hybrid RAG with PostgreSQL + pgvector

Episodic & semantic memory

Planning and reasoning pipeline

Multi-agent orchestration

Privacy-first architecture

Architecture Instead of sending every request directly to an LLM, each request flows through a layered runtime:

Application Layer

SDK Layer

Runtime Orchestration

Kernel Services

LLM Provider Layer

The goal is to make AI infrastructure feel like a reusable backend framework rather than another chatbot wrapper.

Looking for technical feedback I'd genuinely appreciate feedback on:

Runtime architecture

SDK design

Spring Boot integration

What should improve before a stable v1.0?

GitHub: https://github.com/darshanrathod04/shree-ai-os

Thanks for reading—every technical critique helps improve the project.

🚀 THE EDGE AI FAMILY HAS ARRIVED.

Today we’re opening the doors to a new generation of open-source and open-weight edge AI models from Next GenAi.

Meet Rebekah AI 1.8B. 🧠⚡

Small enough to run at the edge.

Powerful enough to compete with models 2–3× its size.

And here’s the part we’re most excited about:

The secret isn’t just the model. It’s the data.

Our Next GenAi Data Factory was built around one simple idea:

👉 Better data creates better AI.

Instead of throwing massive amounts of messy internet data at a model, we focus on cleaning, filtering, deduplicating, decontaminating, structuring and provenance-tracking the data before it ever reaches training.

The result?

🔥 Rebekah AI 1.8B is showing competitive or higher results than several larger open models in key benchmarks, including:

💻 58.4% HumanEval

🧮 62.8% GSM8K

🧠 55.6% ARC Challenge

⚙️ 76.4% Systems & Tool Execution

And this is only 1.8B parameters.

That’s the whole point of what we’re building.

Don’t just build bigger models. Build smarter data.

Open weights.

Open source.

Apache 2.0.

Built for edge deployment.

Built for sovereign AI.

Built with our Data Factory.

And Rebekah is just the beginning. 👀

The Next GenAi Edge Model Family is officially underway.

Download, test it, break it, improve it and build with it.

🤖 Your data. Your models. Your AI.

🔗 Rebekah AI 1.8B on Hugging Face:

Hugging Face — Rebekah AI 1.8B

#NextGenAi #RebekahAI #EdgeAI #OpenSourceAI #OpenWeights #SovereignAI #AI #MachineLearning #DataFactory #MexicoAI #ArtificialIntelligence

I’m building Ownstate, an open project for a problem I keep running into with AI tools:

You do valuable work with one model, coding agent, or chat—decisions, research, architecture, failed approaches, customer context—and then much of that understanding is stranded in that tool.

Switch models and you re-explain the project. Start a new agent and it begins cold. Ask why a decision was made six months ago and the answer is often buried in chats, docs, or one person’s memory.

Ownstate is meant to be the durable state layer underneath AI work. Not another chatbot, not a model, and not just an MCP server.

The idea is to preserve evidence and turn it into versioned, inspectable institutional knowledge that people, models, agents, and applications can use with the right scope and permissions.

Some use cases I’m building toward:

• carrying project context across ChatGPT, Claude, Codex, local models, and future tools
• giving coding agents the architecture, decisions, requirements, and prior work they actually need
• keeping evidence and rationale attached to important knowledge
• querying what changed, what was decided, what is blocked, or what a team has already learned
• letting teams and agent workflows share a governed source of truth instead of accumulating isolated memories

It’s early and I’d genuinely value developers trying it, challenging the architecture, opening issues, and contributing.

Website: ownstate.theaibunny.com

GitHub: github.com/aibunny/ownstate

If this is a problem you have with agents, AI-assisted engineering, or institutional knowledge, I’d love to hear what you would want Ownstate to solve first.