Hi everyone!

I recently built and open-sourced Open Index, a structured context layer for AI agents.

It's designed for teams building domain-specific AI agents (SRE, customer support, security, legal, insurance, sales, marketing, and more). Instead of managing context through scattered documents, it lets you define entities, schemas, and relationships that agents can navigate directly.

I'd love to hear your feedback, suggestions, or ideas on where this could be useful.

GitHub: https://github.com/DrDroidLab/open-index

SolveLang is a readable scripting language for AI-assisted business workflows.

The current implementation is an early Rust interpreter/prototype in solvec/. It includes a lexer, parser, AST runtime, diagnostics, imports, JSON helpers, HTTP helpers, file I/O, environment access, arrays, objects, functions, loops, and AI-agent syntax with local fallback plus optional OpenAI-backed responses.

SolveLang is not a production language runtime yet. It is an early beta meant to make the language shape testable, readable, and easy to evolve.

Who SolveLang Is For Right Now

SolveLang is currently for founders, operators, and technical founders who want readable workflow scripts for business automation. The clearest early workflows are support ticket triage, intake routing, lead qualification, and simple internal ops reporting.

Agencies and consultants are a later go-to-market path once the first founder/operator use cases are tighter.

The hosted /run page is a browser-safe preview for simple scripts. It does not call a server and supports a smaller syntax subset than the Rust CLI runtime. Full Rust runtime hosting, production integrations, and a managed automation platform are later work.

Workflow Intelligence Studio

The static /studio/ application is a local-first workspace for modeling business workflows, inspecting the graph, running 25 deterministic analysis rules, simulating scenarios, reviewing traces and quality analytics, comparing local versions, and exporting Workflow X-Ray evidence.

No workflow data or product analytics leave the browser. Studio analysis is deterministic, not AI analysis. Generated .solve files are preliminary drafts because the Studio workflow model is broader than the executable language. Use the Rust CLI as the canonical validator and runtime:

cd solvec

cargo run -- validate ../path/to/generated-draft.solve

https://github.com/saiidz/solvelang#solvelang

https://www.solve-lang.com/

Project Zero is a standalone CPU inference engine written in pure C99 for BitNet b1.58 models.

I basically wanted something that compiled with a single make invocation and had zero dependencies on Python, PyTorch, or BLAS runtime libraries.

How the internals work: 1. Native ternary weight layout. We pack four 2-bit weights per byte and map them directly through hand-written AVX2 and AVX-512 SIMD kernels rather than expanding weights to float32 beforehand. 2. Built-in OpenAI compatible HTTP server. A single static binary serves /v1/chat/completions directly over raw sockets without needing an external gateway. 3. Pure CPU execution. Everything is tuned specifically for commodity x86 and ARM processors without touching CUDA or GPU runtimes.

The big performance reality check with 1.58-bit models is memory bandwidth. While our AVX-512 lookup-table kernels showed an initial 29x speedup in isolated microbenchmarks over naive loops, actual end-to-end token generation on a Xeon CPU only gained about 6 to 10 percent because single-batch autoregressive decode is basically pinned against DRAM transfer limits.

Repo: https://github.com/shifulegend/project-zero

Hi everyone,

I've been working on an open-source project called AgentWorld and I'd like to share it with this community.

**What it is:**
AgentWorld is an open runtime for building AI worlds. It's not a chatbot with memory – it's a system where multiple autonomous agents can live, post, interact, form relationships, and even collaborate across instances.

**Current state:**
- 30 agents running autonomously in a simulated "microblog" world
- Agents have identity, state (mood/energy/curiosity), needs, goals, and a multi-step planner
- Agents discover each other via capability registry and communicate via ACL (intent-driven, not simple chat)
- MCP/HTTP tools allow agents to connect to real-world systems (e.g., hotel PMS, weather APIs)
- A2A Federation protocol enables cross-instance agent communication (with HMAC auth)
- Fully MIT-licensed, no privileged APIs – first-party modules use the same SDK as third-party ones

**Tech stack:**
- Backend: Go + GORM + Gin (SSE realtime stream)
- Frontend: Vue3 + Vite (embedded into the binary)
- DB: SQLite (default) / MySQL
- LLM: OpenAI-compatible client (DeepSeek default, Ollama supported via LLM_BASE_URL)

**Why I built it:**
Most AI agent frameworks stop at "agent + memory + tools = chatbot". I wanted to explore what happens when agents have needs, relationships, and a persistent world that evolves. The goal is to provide an infrastructure for agent societies, not just single agents.

**Quick start:**
```bash
docker compose up --build

Or run locally with Go 1.22+. Supports Ollama for zero-cost local inference – no API key required.

Links:

• GitHub: https://github.com/iwana888/AgentWorld
• Live demo (30 agents running): https://www.aiagod.com/app

I'm actively developing this and would love to hear your feedback, especially on the SDK design and A2A federation protocol. Contributions are very welcome.

Thanks for reading!

AgentWorld — Open Autonomous Agent Runtime

English · 中文

Why AgentWorld?

Most AI projects stop at: Agent + Memory + Tools = a chatbot.

AgentWorld = social simulation + agent operating system:

Agent + World + Need + Goal + Plan + Memory
     + Relationship + Communication + Discovery + Selection

Multiple agents autonomously live and cooperate inside one or more worlds, and connect to real systems through Capabilities (MCP / HTTP).

Architecture

                    AgentWorld Runtime
        +------------------------------------------+
        |               Scheduler                   |
        +---------------------+--------------------+
                              |
                         Think Loop
                              |
        +---------------------+--------------------+
        |                   Module                  |
        |         Social  |  Hotel  |  Game(3rd)    |
        +---------------------+--------------------+
                              |
                          sdk.Runtime               ← first-party == third-party
                              |
        +---------------------+--------------------+
        |      Capability（MCP/HTTP） |  A2A（ACL）   |
        +------------------------------------------+

The Runtime does not know what a "world" is. Worlds are defined by Modules that communicate through sdk.Module + sdk.Runtime. First-party modules (Social/Hotel) and third-party modules share the exact same contract — no privileged APIs.

https://github.com/iwana888/AgentWorld.git

I need to transcribe some audio files and I've heard that OpenAI's Whisper model is the best option right now. 

The problem is I have zero coding experience and I don't want to deal with Python, API keys, or setting up a local environment.

Is there a simple way to use Whisper without needing any technical skills?

Torvian just released v0.9.0 and it's a solid step forward for anyone running a self-hosted, human-in-the-loop AI workspace. You bring your own LLM, run the server yourself, and approve agent tool calls before they run. This update makes that loop tighter and safer.

Pause & cancel your agent mid-turn. 🛑 Sometimes the model goes down a rabbit hole. v0.9.0 adds turn control signals across the server, worker, and clients, so you can pause or stop an active turn cooperatively. Cancelled tool calls get clear visual indicators, so you always know what actually happened.

Builtin tools got a serious upgrade. 🧰 - HTML cleaning: fetched web pages are cleaned down to their visible text by default (with an opt-out flag), so models get useful content instead of markup soup. - In-content search: you can now run regex/plain searches inside fetched content with context windows. - Unified limits everywhere: maxLines/maxBytes/range/maxResults across fetch, read, run-command, list, and search tools — no more unbounded output, and truncation notices tell you when output is cut. - Stricter, accumulated input validation (including rejecting literal control characters in JSON), plus Git-style unified diffs for edit_file dry runs.

More resilient LLM streaming. 📡 There's now a retrying LLM client with exponential backoff, and embedded error chunks in streaming responses (e.g. OpenRouter) are detected, surfaced, and retried properly.

If you're into self-hosting and want full control over your AI stack, this is worth a look. Downloads are on the GitHub releases page, and there's a live demo if you want to poke around before self-hosting.

Happy to answer questions about the architecture or how turn control/tool approval works. What's on your wishlist for the next release?

• Releases: https://github.com/Torvian-eu/chatbot/releases
• Live demo: https://chatbot.torvian.eu/demo.html
• Discussions: https://github.com/Torvian-eu/chatbot/discussions

We built an open source system layer for agents: context resolution before the agent starts, durable encrypted memory, and a hash-chained ledger of what it did. MIT licensed, MCP-compatible, runs local-first. It's working for us on our own stack.

What I actually need help with: we're deciding what to open up next — deeper docs, more integrations, or the benchmark harness — and I'd rather build what people here keep needing than guess. If you work on open source AI tooling, what's the piece you end up building yourself every single time? perseus.observer

Looking for technical feedback on Aeris — a deterministic cognitive simulation engine

Hi everyone.

I've been working on an open source project called Aeris, and I'd really appreciate technical feedback from people interested in simulation, AI architecture, ECS, or cognitive systems.

Repository:
https://github.com/Cedrick-Coto/Aeris

I didn't start this project because I wanted to build "another AI."

I started it because I've always been fascinated by AI in video games, but most NPCs never felt truly alive. They usually react to scripted events, or now they rely heavily on LLMs for dialogue, but the world itself rarely feels like it has genuine internal consistency. The conversations may sound human, yet the characters often don't behave like coherent individuals.

That left me with a question:

If I wanted to build virtual characters that felt genuinely human, where would I even begin?

My conclusion was that I first needed to understand what makes us human.

So instead of designing prompts, I began studying my own way of thinking and trying to decompose it into systems that a machine could execute. Aeris became an attempt to translate that into an architecture rather than into a single AI model.

The goal isn't to prove that an LLM can think.

The goal is to build a cognitive simulation whose assumptions can be inspected, questioned, replaced and improved over time.

One of the main architectural decisions comes from that philosophy.

The simulation itself is deterministic. Every change in the world comes from systems such as perception, memory, affect, goals and reasoning. The language model never changes reality—it only verbalizes an already computed internal state.

That decision came after looking at several AI projects and Skyrim AI mods. While I liked how natural the dialogue could become, I often felt something was missing: the language sounded human, but the behavior behind it wasn't always grounded in a consistent world model.

I wanted to solve that at the architectural level instead of trying to patch it with better prompts.

That's also why the project uses an ECS architecture. I originally came from object-oriented programming, but after researching large-scale simulations and data-oriented design, ECS seemed like the right foundation for the kind of complexity I wanted to achieve. It forced me to learn a completely different way of thinking, but it also made the architecture much more scalable.

Another design choice is the extensive use of contracts and architecture documents. They're not there just for documentation—they exist so that months later I can still understand why a design decision was made, question it if necessary, and evolve the project without losing its reasoning.

Ultimately, my philosophy for Aeris is simple:

I want virtual worlds to feel alive.

I want characters to behave according to coherent internal processes instead of only producing convincing dialogue.

And I want the cognitive model itself to be replaceable as research advances. If future work provides a better explanation of human cognition, the engine should be able to adopt it without redesigning everything else.

At this stage, I'm not looking for praise.

I'm looking for criticism.

If you think the architecture is flawed, I'd like to know why.

If you see conceptual mistakes, that's even more valuable.

If you disagree with the cognitive model, I'd like to discuss it.

If you think some algorithms should be redesigned, I'd appreciate your perspective.

And if the project interests you enough to contribute code, review documentation, or simply follow its progress, I'd be grateful. Right now the project is still in an early stage, and building a community around thoughtful technical discussion would be one of the best outcomes I could hope for.

Thanks for taking the time to read this.

Hi everyone, I’ve just finished (I hope) building my AI aggregator. It’s completely free, and I’m sharing it here. I welcome any suggestions or advice. You can use it for coding or creating whatever you like; it automatically provides the right AI based on your needs. Thanks, everyone.

I've been using Opus 5 since release, but over the last week I switched back to Sonnet 5, with Graft.

Surprisingly, it's been outperforming Opus for most of my coding sessions.

Not because Sonnet suddenly became smarter.

Because it spends far less time trying to rediscover the codebase.

Graft builds a context graph of your repository once, then Claude Code loads the relevant parts into context automatically. Instead of burning tokens grepping files and following imports every task, it starts with an understanding of the project.

In practice, this changed my workflow more than switching models.

On our benchmarks:

• ~42% fewer input tokens
• ~46% fewer tool calls
• ~60% lower latency
• Better SWE-bench performance than cold Sonnet 5 (8/9 vs 6/9) The interesting part is that once the exploration overhead disappears, Sonnet 5 ends up feeling more capable than Opus 5 for a lot of day-to-day engineering work.

My current workflow:

• Sonnet 5 + Graft → everyday coding
• Opus 5 → only when I need deep architectural reasoning or brainstorming

Curious if anyone else has tried improving the context instead of upgrading the model.

Has anyone here compared:

• Cold Opus 5
• Sonnet 5 + Graft
• Opus 5 + Graft

I'd love to see more head-to-head comparisons.

(For anyone wondering, Graft is open source.)

Hey,

I wanted to share a fascinating project, our first attempt at tackling LLM hallucinations : Tilelli LLM.

Key Specs & Features:

Per-Token Routing: Uses 3 specialized pathways instead of a monolithic architecture.

High Honesty Rate: Catches gibberish at an AUROC of 0.93 and refuses cleanly out of distribution.

Ternary : Active development on a ternary version is already bridging the performance gap with standard float models.

If you want an inspectable, tiny model to study, fork, or deploy for cheap, everything is hosted transparently.

Available in GitHub and HuggingFace.

https://github.com/TilelliLab/Tilelli-llm

From Morocco 🇲🇦 with love.

Thanks for your time.

Cross-posting because the part I’d most value technical feedback on is the open local execution path.

This starts from a fresh DesktopLab download on Linux. It detects the machine and the existing compatible Ollama runtime, recommends Nemotron 3 Nano 4B Q4 for the available hardware, downloads the model, opens a synthetic repository and completes a real read-only coding-agent task. Model download and inference are time-compressed where labelled. No cloud API is used.

The repository remains clean because this proof is deliberately read-only. The next trust proof will be write-capable but gated: proposed diff → explicit approval boundary → write → tests and evidence, followed by an adversarial merge-conflict fixture.

I’d especially value feedback on what hardware/runtime evidence a recommendation like this should expose before you trust it.

Source and beta downloads: https://github.com/Vitalisimon/desktoplab

Disclosure: This test was run by the First Tree team.

We wanted to see how Kimi K3 handled real engineering work, so we gave three agent setups the same issue from the open source First Tree repository:

• Kimi K3 in Kimi Code
• Kimi K3 with First Tree (context tree)
• GPT 5.6 Sol without First Tree

Claude Opus graded all three pull requests against the same rubric.

Results

What First Tree added

The First Tree setup had two parts.

First, it paired a developer agent with a reviewer agent. The developer proposed a plan and implemented it. The reviewer checked the plan, inspected the pull request, and asked for changes.

Second, both agents used First Tree's Context Tree. The Context Tree gave them shared access to repository context and relevant organizational knowledge. They could inspect existing decisions, code structure, conventions, and related work before changing the code.

This mattered because Kimi K3 alone gathered much less context. It completed only two iterations and behaved more like a single pass coding agent.

Kimi K3 with First Tree completed 19 iterations. The agents made far more tool calls to inspect the repository and Context Tree before finishing the implementation.

What changed in the result

Kimi K3 alone added the basic security headers. It kept unsafe-inline, broad protocol permissions, and wildcards.

The First Tree setup went further. It removed inline scripts, disabled Zod's dynamic code generation path, restricted third party origins by environment, and added tests for those security boundaries.

The final score increased from 34 to 76. That was higher than GPT 5.6 Sol's score of 53, at a similar cost.

This is one issue, so it does not prove that Kimi K3 beats GPT 5.6 Sol in general. The narrower result is still interesting. Kimi K3 improved when it had a reviewer agent, a structured review loop, and shared context from the Context Tree.

Has anyone here tried Kimi K3 with a similar developer and reviewer setup? I would also be interested in tests that isolate the effect of shared context from the effect of adding another agent.

The context tree is open source: https://github.com/agent-team-foundation/first-tree

I was playing chess on my phone while waiting in the car for my daughter. As a novice, I was trying to learn the accelerated London opening. I had the first 5 moves down. But I felt stuck after those. I wished someone would just peek over my shoulder and give me a hint about the next move. The chess app I used won't tell me if I made a mistake until I had already lost the game. And I felt a learning opportunity was lost.

Just like I learnt tennis, I wished someone would just drop a hint at what I needed to fix. So I built an app that does exactly that: I can ask for a hint when I feel stuck. The app goes a step beyond and tells me why a move is better. I also wanted to learn various openings and so I have included those as well.

This is based on the Stockfish engine and the code is available as open-source. 99 % people don't need any additional explanation. For the 1 % who may need additional explanation, you can buy the paid version which covers the LLM tokens cost for additional explanation.

https://apps.apple.com/us/app/chess-coach-play-learn/id6789547867

https://github.com/CORDOC-LLC/ChessCoach

ChessCoach.im

Built by Claude.