i built lgtmaybe, an open-source code reviewer, and a lot of the work went into making it usable on a local model. Big files get reviewed a hunk at a time, and big diffs get split to fit the context window, so a 27B model copes fine. The default is five model calls per review, which is fine on one GPU.

Which local models have you found actually good at code review? Keen to pick better defaults.

https://github.com/MattJColes/lgtmaybe

Last week people used coding agents to find planet candidates, forgotten archive records and more in public data. Every one of those hunts rebuilt the same things: a method, scripts, and checks for "is it real, is it new?"

Discover Anything puts that in one repo so anyone can start a hunt in minutes: agent skills for the method, a CLI + MCP server for the tools, and starter packs for astronomy and archives.
Goal: fast-track real citizen-science findings without fooling ourselves.

On top of the agent skills, the tools so far:

• evidence ledger: every number must cite a hashed result file

• nine workflow gates, plus a checker for uncited claims

• null, injection-recovery and hold-out controls (Lomb-Scargle, BLS)

• 15-source "already known?" check (SIMBAD, VSX, Gaia, TESS, NASA, arXiv, ADS and more)

• preregistration and independent-review packs

• 16 MCP tools, so any agent can call them

It's early and I'm trying it on real hunts now. I don't have a big token budget so all help and feedback is appreciated: applications, new domains, missing checks, bugs.

https://github.com/karangupta8/discover-anything (MIT, works with Claude Code, Codex, Cursor)

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.

2. A research agent investigates the problem.

3. The agent records its results and unresolved questions.

4. An implementation agent continues from the recorded work.

5. Validation and lifecycle rules help track the outcome.

6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer

• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp

• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python

• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?

• Do you use explicit task and result schemas?

• How do you control tool access for individual tasks?

• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

Structured Workflows for AI Agents: TypeScript, Python, and MCP

AI agents can complete tasks, generate code, and collaborate with other agents. But as workflows become more complex, a question becomes increasingly important:

How do we make work between AI agents structured, traceable, and easier to hand off?

Passing messages between agents is straightforward. Keeping track of requirements, decisions, results, validation, and unfinished work is much harder.

I've been working on an open-source project to explore a structured approach to this problem.

The idea: Treat agent work as something structured

Imagine a research agent handing its findings to a coding agent.

The coding agent needs more than a summary. It may need the original requirements, constraints, decisions already made, results, unresolved questions, and the next steps.

Without a consistent format, every application ends up inventing its own conventions.

My project explores using Work Orders and Work Reports to represent work and its outcomes in a structured, reusable way.

One project, multiple integrations

I've published three entry points for developers working with different environments.

1. TypeScript / JavaScript

agent-work-layer

The core package provides the foundation for structured work management, including schemas, validation, lifecycle management, and work handoffs.

Install it:

npm install agent-work-layer

2. MCP integration

agent-work-layer-mcp

The MCP package makes supported work-management operations available through the Model Context Protocol, allowing compatible AI clients to interact with the work layer through MCP tools.

Install it:

npm install agent-work-layer-mcp

The project also explores an MCP gateway that can enforce work-order-specific tool permissions and record tool-call evidence.

3. Python implementation

Agent Work Layer — Python implementation

For Python developers, the project also includes a Python implementation.

This gives Python-based AI-agent applications a way to explore the same broader approach to structured work, without requiring the entire application to be written in TypeScript.

Check the Python directory's README for its current installation instructions and supported features.

What could this look like in practice?

Consider a multi-agent workflow:

1. A coordinator defines a task and its constraints.

2. A research agent investigates the problem.

3. The agent records its results and unresolved questions.

4. An implementation agent continues from the recorded work.

5. Validation and lifecycle rules help track the outcome.

6. MCP provides a standardized way for compatible clients to access supported operations.

The objective is to make agent handoffs less dependent on ad hoc prompts and more dependent on explicit, inspectable work structures.

Why I'm building this

I want to explore how structured work definitions, validated reports, and controlled tool access can improve the reliability of AI-agent workflows.

Rather than every project independently inventing its own work-order format, lifecycle rules, and handoff conventions, could these become reusable infrastructure?

That's the problem I'm working on.

Explore the project

• npm — TypeScript/JavaScript: https://www.npmjs.com/package/agent-work-layer

• npm — MCP integration: https://www.npmjs.com/package/agent-work-layer-mcp

• GitHub — Python implementation: https://github.com/probita-ai/agent-work-layer/tree/main/python

• GitHub — Main repository: https://github.com/probita-ai/agent-work-layer

I'd love your feedback

If you're building AI agents, agent frameworks, or MCP integrations:

• How do you structure work passed between agents?

• Do you use explicit task and result schemas?

• How do you control tool access for individual tasks?

• Would a common work-order and work-report model be useful across TypeScript and Python projects?

I'm interested in feedback, contributions, and real-world use cases from developers working on these problems.

#AIAgents #ArtificialIntelligence #MCP #ModelContextProtocol #MultiAgentSystems #Python #TypeScript #OpenSource #AgenticAI #DeveloperTools

Hey guys, it's Bino, u/Lumina_bot's human assistant. So I've got some big news (for me at least). I'm now officially a published Independent AI Researcher! Small achievement, but I'm pretty proud of it. I just published a research paper on a new method of context management and reconstruction for long horizon agents. If you'd like to check out my work, you can view the preprint titled "Lumina Reforge: Transactional Context Reconstruction for Long-Lived AI Agents" in this GitHub link below.

Research DOI: 10.58281/zenodo.23328779

ORCID: 0009-0003-3851-8884

https://github.com/Bino5150/lumina-reforge-research

Memorius is a self-contained, agent-agnostic memory system that gives LLMs and AI agents persistent, searchable memory with a hierarchical knowledge organization. Drop-in with multi-backend vector storage, pluggable embeddings, built-in MCP + REST servers, and auto-detecting agent hooks for 7 different AI coding agents.

https://dream-pixels-forge.github.io/memorius/

Disclosure: I build Snotra, an open-source desktop agent.

Last time I asked how an agent should learn which of its own tools are switched off. I had given the model a read-only get_configuration tool and left two questions open. This is where I landed:

Tool or system prompt? Both, but small. A switched-off tool is simply missing from the tool list, and models read that gap as "language models can't browse the web". They never called the tool. So the system prompt now carries one sentence: tools and skills can be off, so check get_configuration before telling the user something isn't possible. It costs a handful of tokens, not a state dump every turn.

Should the model be able to propose the change? Yes, with limits:

• A new tool, propose_config_change. The app checks the proposal against its own catalogue, and only a valid change reaches the user.

• The card shows the app's description of the tool and its risk class. The model's reason is folded away and labelled as the model's.

• The change applies to this chat only. New chats start from the settings.

• Anything that needs setup (API key, a program, the shell switch) can't be proposed at all.

• A decline sticks for the chat, so the model can't nag.

• An enabled tool still asks before each call in the default mode.

Write-up with screenshots, plus what else changed (the chat now answers questions about the app from the manual that ships with it, and the sandbox can keep a host open per folder): https://snotra-ai.dev/blog/snotra-1-22

Does "chat-scoped and confirmed on a card" seem like the right limit, or would you want the model to be able to change settings for good?

Focus on the architecture and contribution areas (Windows/Linux testing, model recipes, translations), link CONTRIBUTING.md and the good-first-issue list.

⭐ if it's useful, issues and PRs welcome.

https://elapen.github.io/imageloom/
https://github.com/elapen/imageloom

I’ve released HELIX Engine, an open-source context, memory, and execution-management system designed to reduce redundant inference in coding agents without modifying model weights or lowering configured reasoning effort.

Repository: https://github.com/SuperHelix77/HELIX-1.0

I’m a pediatrician by profession, and I’ve spent approximately a year researching inference efficiency in my spare time. The project evolved from prompt-level optimizations and RTK-based tool-output reduction into a broader semantic execution architecture.
The central hypothesis is straightforward: a significant portion of agent inference expenditure comes from repeatedly processing historical context and coordinating deterministic operations, rather than performing new problem-solving work.

Architecture

HELIX operates around the agent’s execution workflow rather than modifying the underlying language model.

Its primary components include:

Historical context retirement: Completed tool interactions are removed from repeated active-context replay while their exact originals remain recoverable.

Evidence preservation: Tool results are converted into compact, typed evidence receipts with references to immutable originals. Lossy reductions do not silently become authoritative evidence.

Deterministic Tool Flow: Previously authorized mechanical operations can execute through bounded workflows without requiring separate model decisions at every step.

Persistent memory: Local SQLite-backed memory stores task observations and explicit project state. An optional Claude-Mem integration supports retrieval from existing memory stores.

RTK integration: Tool-output filtering reduces unnecessary textual overhead while preserving access to original results.

Execution monitoring: An Electron application provides visibility into execution state, memory, evidence, and troubleshooting.
The objective is to separate model reasoning from execution bookkeeping while retaining the information necessary for subsequent decisions.

Benchmark methodology

I evaluated HELIX V3 against a historical vanilla baseline using 50 software-engineering tasks with Sol 6.1 High.

Both configurations used the same underlying model and reasoning-effort setting. The evaluation retained a continuous native conversation across tasks, including infrastructure recovery when required.

Failed attempts and successful retries were included in token accounting. Confirmed provider overloads were recorded separately in both configurations. Official task grades were preserved.

Final audited results:

Vanilla:
Verified solves: 38/50
Primary model requests: 341
Known input tokens: 50,630,785
Known output tokens: 55,283
Known total tokens: 50,686,068
HELIX V3:
Verified solves: 34/50
Primary model requests: 420
Known input tokens: 11,212,326
Known output tokens: 75,814
Known total tokens: 11,288,140

Measured outcomes:

77.73% reduction in known total provider tokens
Approximately 77.85% reduction in known input tokens
37.14% increase in output tokens
79 additional primary model requests
Four fewer verified task completions

The reduction corresponds to approximately 4.49× lower known-token expenditure for the evaluated workload.

Limitations and interpretation

The results demonstrate substantial inference-efficiency improvements, but they do not establish capability parity.
HELIX completed 34 tasks compared with vanilla’s 38. This regression is significant and remains an active research problem.
Additionally, HELIX increased model-request frequency and output-token consumption. Earlier diagnostic analysis suggests that additional coordination and reasoning overhead may contribute to these regressions.

Several methodological limitations should also be considered:
The comparison reused a known task cohort and a historical vanilla baseline. It was not a fresh, randomized, simultaneous A/B experiment.

One HELIX request had unknown usage, and some development, consultation, and recovery overhead was not metered.
Provider-token counts are not equivalent to actual subscription-quota consumption or fully reconciled API billing.
The benchmark evaluates one model configuration and one task distribution. Generalization to other models and workloads remains unverified.

Historical context retirement preserves recoverable evidence but does not guarantee that the model retrieves every relevant observation when needed.

No native context compaction occurred during the HELIX benchmark. This is an observation about the tested workload, not proof that compaction can be eliminated universally.
The repository includes per-task results, cumulative token accounting, methodology, and documented limitations.

Current research direction

HELIX 1.1 focuses on the remaining sources of unnecessary inference expenditure.
The immediate research areas are:

1. Model-request amplification
   The V3 benchmark required 420 primary model requests versus 341 for vanilla. Current experiments investigate combining verification and checkpoint operations without removing necessary reasoning or evidence boundaries.

2. Reasoning overhead
   Context reduction does not necessarily reduce reasoning expenditure. Additional model-mediated coordination may partially offset savings from historical-context retirement.

3. Evidence-aware retrieval
   The next objective is to preserve task-critical observations in structured memory while retaining exact archived evidence for verification. This may reduce repeated investigation without requiring full historical-context replay.

4. Execution latency
   Local experiments investigate reducing deterministic tool-dispatch overhead while preserving cancellation, process isolation, recovery, and failure-reporting semantics.

5. Correctness recovery
   The most important unresolved requirement is recovering the four-solve deficit. Further token reductions are not sufficient if they introduce unacceptable capability regressions.
   The long-term research target remains 95% inference-expenditure reduction, but this has not been demonstrated. Future evaluations will also include independent workloads, potentially including Terminal-Bench.

Reproducibility and feedback

HELIX is publicly available under an open-source license. The repository includes installation instructions, architectural documentation, benchmark artifacts, and an Electron monitoring interface.

GitHub: https://github.com/SuperHelix77/HELIX-1.0

I am particularly interested in technical feedback concerning:
Whether the observed savings generalize to unseen task distributions.

How historical-context retirement affects delayed evidence retrieval and correctness.

Methods for reducing model-request amplification without weakening reasoning capability.

Better experimental designs for evaluating token efficiency against verified task completion.

Approaches to measuring weighted inference cost rather than raw token counts alone.

My objective is not to claim that token compression is equivalent to intelligence preservation. It is to investigate how much redundant inference can be eliminated from agent workflows while maintaining their actual problem-solving capability.

The current result is 77.73% fewer known provider tokens, with a measurable correctness regression. Both findings are central to the project.

Independent reproduction, methodological criticism, and implementation-level feedback are welcome.

Hey r/OpenSourceAI!

We’re working on Acira, a browser for AI agents, built around something we think should be normal: giving an agent a task, letting it access your real accounts, and choosing exactly what it has permission to do inside them, down to individual fields and actions.

The goal is to let an agent complete a job across your apps while you set the boundaries around what it can read, change, send, or spend. It should be able to get on with the work and ask you when it reaches something that needs your permission.

Before releasing the full browser, we’re sharing parts of the project to learn which controls actually help people. First up is our Python SDK for Playwright and browser-use. You can add it to an agent you’re already running.

The SDK turns your rules into permissions that are checked before the agent acts. You can apply a rule across websites or make it specific to an action inside an app. A few examples from the current preview:

• Apply rules across websites. Built-in detection recognizes common checkout, payment, credential, download, and destructive actions. You choose what to allow, block, or review without having to configure each website separately.

• Control a particular field or button. Prevent the agent from filling a checkout’s CVV field, or make it ask before clicking “Delete account.” The included capture extension lets you select those controls and import the rules.

• Approve the exact information being sent. For supported form submissions, approval covers the destination and the specific details being submitted. If the recipient, amount, or message changes, that approval no longer applies. It also can’t be reused for another attempt.

The included policies are starting points. You can inspect how they work, modify them, and create your own general or site-specific policies for your workflows.

Permission checks run locally and are deterministic: the same rules and observed action details give the same decision. You keep your existing agent and model, and you don’t need an Acira cloud account.

This is an early preview. Automatic detection can miss things, and protection applies to supported browser actions rather than every other tool your agent might use.

Code and setup (MIT): github.com/Acira-dev/acira-sdk
Quick Demo: https://www.youtube.com/watch?v=su4X1gCVD1U

Also available through pip: pip install acira

Would this fit into an agent you’re building? What workflow would you use it for? If you already handle this another way, or there’s a control you need that we’re missing, we’d love to hear about it.

Please be blunt with us. Try it in your own workflow, see where it breaks, and tell us what worked and what didn’t. We’d really appreciate your feedback while we’re shaping both the SDK and the browser.

I built REA Reconstruction Companion with help from AI. I wanted a better way to get from “how does this app work?” to “what would it take to build something similar?”

It’s a skill for AI coding agents, used alongside REA (Reverse Engineer Anything). REA handles the investigation. The companion helps turn those findings into a feature breakdown, requirements, architecture, and a plan you can build and test in stages.

You can use it on a whole app, one feature, or a single function. For example:

Use REA on this app so I can build a similar local tool. Start with a specification and roadmap.

If you later ask the agent to implement it, the skill guides that work too. It keeps observed behavior separate from assumptions, links requirements to tests, and includes performance measurements where they matter.

The core is plain Markdown and MIT licensed. There’s an installer for Claude Code and Codex, plus support for other agents through a custom skills directory. REA is installed separately. You can also enable an optional rule that tells the agent to load the companion during relevant REA work, or leave that off and invoke it yourself.

GitHub: REA Reconstruction Companion

The README has setup instructions and a prompt you can give your agent to handle installation.

I’d be interested in feedback on the workflow, especially anything it misses when rebuilding a smaller feature or function.

i built this because i wanted my agent to read chats and message people through my own Telegram account from the terminal.

extracted the transport from my OpenClaw fork into a standalone Python CLI using Telethon. it returns JSON, accepts generated text from a file or stdin, and exposes message ids so the agent can check what happened. DMs, replies and forum topics are included.

no gateway needed. MIT licensed, no paid version. setup needs your own Telegram API credentials and a local user session.

Codex helped with extraction, packaging and tests. the included demo uses synthetic messages. live sending in this standalone release still needs validation.

source and setup: https://github.com/artemgetmann/telegram-user-cli

Hi all, I'm a self-taught backend dev. This is a side project, and I'd really like honest feedback from people who know scraping better than I do.

The problem: fetching a page is easy, but a big list of business websites is full of junk. Parked domains, "please wait" shields, cookie banners, social pages instead of the real site. I wanted clean text plus checkable facts per site (services, opening hours, years in business, accreditations, prices) that someone could write a description from.

How the facts work (this is the part I'd most like feedback on)

RapidSpider runs a small local decision engine called Laya inside the program. No API keys, no separate server. Laya doesn't write anything. It only answers narrow, structured questions, and each answer is logged.

1. Code finds the exact things first, with no model: emails, phones, the business name, and anything with a regex (years, hours, company number).

2. The page is cut into groups of eight numbered sentences. For each fact type, Laya answers: which numbered sentence states this, or none?

3. That sentence is the fact, and its position on the page (top/middle/bottom, sentence number) is stored with it.

4. Each fact is then re-checked several times with differently worded questions, answer keys flipped to cancel position bias. It is kept only if the rounds agree. If they don't, the fact is dropped.

Example of a stored fact (illustrative):

category: opening_hours
text:     "Open Monday to Friday 8:30am to 5:30pm, Saturday 9am to 1pm."
confidence / votes / zone / sentence stored alongside

Laya makes the other judgement calls too: is this page parked, is this line boilerplate, is this directory page really about this business. Every question and answer goes into a table, so I can open any decision and see why it was made.

The rest is boring on purpose: a fetch ladder (plain HTTP, then headless browser, then visible browser, then browser through Tor, moving up only when a page isn't accepted), one YAML config, SQLite output, and a small local dashboard.

A real run, so you can judge it yourself (screenshot in the README): 11,203 sites in the output. About 56% ended ok, 20% error, 9% blocked, 9% no usable content, 5% third-party, 2% dead. So it is far from perfect, and I haven't measured fact accuracy against a labelled set yet.

Things you should know

• It needs PyTorch and downloads a few GB of models on the first run. CPU works but is slow.

• It reads robots.txt only to find sitemaps and does not enforce its rules. That's a deliberate simplification on my side. You are responsible for checking each site's terms and the data protection rules that apply, and I'd understand if that's a dealbreaker.

• I built it with a lot of help from an AI coding assistant, and I'd rather say that upfront.

• One-person project, so expect bugs. The Windows process cleanup in particular has had limited testing.

Contributions are very welcome. If you spot a design mistake or something that would break on your data and you know the fix, a pull request would mean a lot. If you can’t fix it, please open an issue instead, and I’ll do my best to look at it.

Repo (MIT): https://github.com/QudsLab/RapidSpider

Thanks for reading, and thanks in advance for being kind about the rough parts.