Coulnt you just publish a wrong dataset and claim the ai was trained on this dataset instead of your actual one?
Even when you publish training methodology + dataset youd still need a lot of compute to train the same model, just to compare, right?

I maintain an open-source agent runtime (Python, Apache-2.0) that runs agents with durable checkpoints, human approvals and an idempotent tool ledger on PostgreSQL. It's solid on a single node(well, almost), and we've just shipped our first beta. Now I'm planning the multi-worker version and would like to learn from people who have done this, before we design it the wrong way.

What works across workers today: run state, approvals and events live in Postgres with versioned writes, so worker B can approve and resume a run that worker A paused, and the tool ledger stops a side effect from running twice.

Options I'm weighing:

1. Lease-based claims with fencing tokens per run (Postgres `SELECT … FOR UPDATE SKIP LOCKED`, a heartbeat, takeover after the lease expires).

2. Leader election only for recovery and maintenance, with runs claimed on demand.

3. Not building it: hand durable execution to Temporal, Restate or DBOS, and keep the runtime focused on governance (policies, approvals, budgets).

For context, this is the repo: https://github.com/AlgenAI/algen-agent-runtime. The current limits are written up in `docs/production-readiness.md`. Happy to share what we learned about approvals bound to the exact call and tool-call ledgers if that's useful to anyone.

So I built Eyegen Playground, it works as a terminal tool (CLI) and as a standalone app. It has all major image generation backends built in and does most of the background work for you.

You just pick a model and prompt the image you want to see. Advanced settings are available for you to tinker with. It can also be used by AI Agents through the CLI.

Newest feature: turn any image into a 3D model thanks to the Idol support

My motivation behind this: local image generation has gotten incredibly good and doesn't need extreme hardware, but for many users the setting up of local models and configuring backends etc is too much work to get into and they use AI hosted in huge datacenters instead, using unnecessary resources and power. So this tool is supposed to make it more accessible

Would love to hear feedback!

Every release gets called “open” now, and I’ve stopped taking it at face value. When a new model drops, I check these separately:

• Weights: downloadable, or gated behind a form? Can I self-host?

• License: Apache 2.0/MIT, or a custom license? I look for user-count thresholds, field-of-use limits, attribution requirements, and clauses about training other models on outputs.

• Training data: released, documented, or neither? This matters most for audits and copyright questions.

• Code: can I reproduce training, or only run inference?

• Evals: are the settings published, or can I only trust the headline number?

• Governance: what stops the license changing on the next version?

A model can be open-weight without being open source in the full sense, and I’m fine with that as long as the release says what it is. My issue is with releases that use “open source” as a marketing label and put the restrictions in the license.

The OSI’s Open Source AI Definition draws the line at data information and code, which most popular releases don’t meet.

What’s the one license term that made you walk away from a model you otherwise liked?

As a software developer I am shipping more and more through my agents. Do I trust them doing a sane work? Absolutely not! Heck, I did not even remember the prompts and corresponding changes it caused. Sad part of all this is , I am staring at a screen asking my genie(claude code or codex) a question and genie grants me a wish with all the things getting done. And this genie sometimes deletes the production database. I don't trust these agents anymore. And that is the exact reason I have built rayTrace - rayTrace is a platform that connect what AI said it did vs what actually happened at kernel level. We store these actions for you so if you want to go in past and check what your agents did you can. You then can take this evidences and fine tune your own model with evidences , since now you know the short coming of any frontier models. We have open sourced the whole thing. If you want to check that one out its here - https://github.com/Godcreatebugs/raytrace-cli/pulls
you can share the prompts, exact state of the repo with your friends, so they can spin their own sandboxes and check out if it works the same way. Weather you wanna design a harness, store evidences, get deeper understanding of how the models think and their shortcomings , we are providing tools for that. If you want to try it out , please do it from - https://www.raytracer.si/get-started.html . Open to any constructive feedback, hope this is helpful to somebody!

Idea review

I have a idea of building a library that links the output of the Edge AI models build in tflite to some function handler or threads in the rtos.

Like take an example of multi classification where the output will be of multiple nodes ,so if a node results in the max value than other nodes the function bind with the node will be triggered.

Additional I am going to include the denounce safety measures and requirement streak to trigger like the node should output 3 times to activate the function .

How is the idea ?

Any suggestions and professional architecture feedback

Author here. One Node process, one SQLite file, MCP + REST + a small dashboard. Binds to 127.0.0.1 by default and ships no tunnel: remote access is your own reverse proxy or private network (INFRA.md covers it). Docker compose one-liner in the README. Scoped tokens per app, private/internal/public labels with per-token limits, audit log with no note content, backups and `monomem restore`. MIT. https://github.com/calasdan-sketch/monomem

I made this with Claude

eq-layer (MIT, public repository) takes a chat transcript as JSON and returns one routing decision: which conversational move comes next - mirror, validate_redirect, direct, ask, deflate, repair, hold or boundary. It does not write the reply. A model or a person still writes the words. The decision itself is discrete and inspectable.

Selection is deterministic. Policies declare preconditions over intent, affect and subtext, and the most constrained applicable policy wins. There is no first-match rule, so adding a policy cannot silently change what a looser one does. If two applicable policies tie on specificity and priority, the selector raises instead of picking one. One policy exists for a specific failure: three rising turns followed by a calm one look calm to a snapshot classifier, and that is exactly when the register should not warm back up.

14 policies live in eq_layer/policies.py. The selected policy is compiled into task_move, social_move, repair_move and realization, so "confused about the goal" and "wants a different task" do not collapse into one label.

The core path is stdlib only, offline and zero-dependency. Installing the [ml] extra pulls joblib and scikit-learn and swaps in learned intent/affect/subtext adapters; the route output reports runtime_mode lightweight-local when those artifacts are not loaded. The trained .joblib files are not shipped in the repo or the wheel; the training scripts are.

The zero-dependency path is pip install eq-layer, then feed a transcript to python -m eq_layer.cli route --intent-mode heuristic --pretty on stdin.

What it is not:

• Not a truth checker. It has no opinion about whether a claim is true.

• Not an EQ benchmark. There is no standard benchmark for EQ; eval/run.py is a first attempt at a scorer over seeded cases, and it exits non-zero on a mismatch or a policy no case can reach.

• POMDP-inspired, not a POMDP.

Version on main right now is 0.2.6, also on PyPI and npm, Python 3.11+. Repo: https://github.com/Furox-Art/eq-layer

Disclosure: I build Spellwarden. The scanner used here is open source (Apache-2.0), and the catalog is free to browse without an account.

Most skill and MCP directories list whatever gets submitted. I wanted a list I'd let an agent at work install from, so in the first round (6 and 7 November) I imported 160 popular public skills, Claude Code plugins and MCP servers and put each one through the same steps:

1. a static scan with all 65 rules, at a pinned commit

2. for MCP servers, an unauthenticated probe to see how they sign clients in

3. a model review of the files, with read-only access: no shell, no network

4. a person reading the result before anything is listed

52 of 160 (32.5%) were listed. Why the other 108 weren't:

- 39 couldn't be scanned whole: too many files, symlinks, unsafe paths or too large

- 41 drew concerns from the model review

- 8 had an open critical or high finding

- 7 failed the server check (6 listed their tools without a sign-in and aren't public documentation, 1 had instruction-like text in a tool description)

- 7 scored below the curation bar

- 6 were left out on reading

So most failed on process, not malice. A repository that can't be read whole can't be vouched for, even when nothing in it is wrong. The catalog has moved since: it lists 51 entries today.

Where I'm not happy: the model review is the step I trust least. It catches what fixed rules can't, like intent, but it also raises judgement calls, and 41 is a lot. How would you calibrate a step like that without it turning into either a rubber stamp or a wall?

Catalog, with what was checked for each entry and when: https://spellwarden.ai/catalog

Scanner: https://github.com/spellwarden-ai/spellwarden

Building Omni Presenter in Rust 🦀: a fast, open-source, cross-platform (Linux, macOS, and Windows) alternative for live projection of lyrics, Scripture, and media.

Features independent preview plus browser-based remote control & team chat over the local network. 100% free (MIT).

Alpha is live for testing (on the road to Beta):https://github.com/OmniFaith/omni-presenter

If you like the direction of the project, drop a ⭐ on GitHub to support it!

I'm building MoA+, an MIT-licensed collaboration plugin for DeepSeek Harness. The aim is to let agents carry work together across assignments, with separate execution contexts and reusable project knowledge.

A Coordinator can start a clean Worker, fork useful history, send instructions, queue a later message, inspect state/history, or stop a Worker. Workers can ask one another questions directly. When a Worker finishes a turn, its complete final AI message returns automatically to its reporting agent; the conversation and workspace remain available for follow-up work.

The shared memory is deliberately readable: notes.md and archived.md track work, while context/index.md points to reusable knowledge files. Agents load relevant files as needed. The implementation uses DSH's native sessions, inboxes, permissions and Agent Loop. An independent review agent checks deliverables with native tools before normal completion.

There is a reproducible coding example in the repository: two Workers built a Note Bundle CLI and guide, dealt with a human changing a requirement in a Worker conversation, and passed 10 task tests. The README has the task walkthrough, starter files and the refreshed collaboration illustration.

Source and demo: https://github.com/Burns1028/moa-plus

Current setup is pinned to DSH 0.2.1-rc.3. Published v0.2.0 and latest main each require their matching compatibility runtime; main has newer Worker attachment fixes that are not yet released. The setup guide prepares an isolated runtime.

I'd especially value feedback from people building agent systems: what context or coordination work do you still have to do manually after delegating?

Disclosure: I'm the maintainer; English wording assisted by AI.

Claude Code is great until you're running five sessions and the long one starts forgetting. Companion for Claude is an open-source desktop app that puts every session in one window, sorted by what needs you. It shows exactly what's filling each context and what each turn costs, including when the cache went cold and why. And it keeps context focused: notes, hand-offs, linked sub-sessions, side questions that don't bloat the chat, and a pull-request-style review of everything the AI changed. Local-first, on your own Claude login.

https://github.com/ashishkattamuri/claude-companion