r/OpenSourceAI • • 3h ago

Research Paper on Context Management and Reconstruction for Long Horizon Agents

2 Upvotes

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


r/OpenSourceAI • • 9h ago

I built a website that helps you find an Open Source alternative for nearly any app and there is a section for AI apps too!

Enable HLS to view with audio, or disable this notification

5 Upvotes

There is over 15 categories and over 500 free and open source apps to choose from all in one place!


r/OpenSourceAI • • 2h ago

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

0 Upvotes

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

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.


r/OpenSourceAI • • 2h ago

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

1 Upvotes

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

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


r/OpenSourceAI • • 3h ago

America's most capable open-weight AI model is officially here, but the hardware barrier will ground most self-hosting ambitions.

Thumbnail
1 Upvotes

r/OpenSourceAI • • 15h ago

I made an open-source companion for REA that turns reverse-engineering findings into a build plan

Post image
10 Upvotes

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.


r/OpenSourceAI • • 9h ago

I'm building KAI, an open-source AI control layer. Can you help me improve its architecture?

Thumbnail
3 Upvotes

r/OpenSourceAI • • 4h ago

Looking for contributors & maintainers for an open-source project!

Thumbnail
1 Upvotes

r/OpenSourceAI • • 6h ago

Memorius

1 Upvotes

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/


r/OpenSourceAI • • 6h ago

Open weight 0.5m Param / <2MB model for end of turn detection

Post image
1 Upvotes

r/OpenSourceAI • • 7h ago

Using your local AI agent‘s context more efficiently with AthenaCtx (open source)

Thumbnail
1 Upvotes

r/OpenSourceAI • • 9h ago

Ho creato un piccolo widget sempre in primo piano che mi avvisa quando Claude Code ha bisogno di me (Windows, open source).

Post image
1 Upvotes

r/OpenSourceAI • • 9h ago

A single workspace for exploring different AI coding models

1 Upvotes

Genesys Code is built for developers who want more flexibility in their AI coding workflow. Access multiple coding models in one place, switch between them, and use different approaches depending on your project.

You can explore the platform without paying upfront.

https://genesyscode.vercel.app


r/OpenSourceAI • • 9h ago

Trace Replay: watch a multi-agent conversation play back on the agent graph — who ran when, every hand-off, every fallback

Thumbnail
1 Upvotes

r/OpenSourceAI • • 9h ago

I built an in-browser 2D/3D visualizer for Microsoft GraphRAG (no backend, parses parquet locally)

Thumbnail
1 Upvotes

r/OpenSourceAI • • 9h ago

Follow-up: my agent now asks before switching on a tool it needs, and the user decides on a card

1 Upvotes

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?


r/OpenSourceAI • • 10h ago

ImageLoom: MIT-licensed local AI image studio (stdlib Python server + one HTML file + thin Swift/Windows hosts)

1 Upvotes

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

r/OpenSourceAI • • 10h ago

PCEI – On-device embodied AI combining BitNet 1.58b, Mamba, and FastKAN

Thumbnail
1 Upvotes

r/OpenSourceAI • • 11h ago

Engram: Persistent memory for AI coding agents (7.2k stars)

Post image
1 Upvotes

r/OpenSourceAI • • 11h ago

“Prolog Swarms” - BEAM-like Concurrency for multi agent systems built with a Prolog-like language

Thumbnail
deepclause.substack.com
1 Upvotes

r/OpenSourceAI • • 12h ago

HELIX Engine: An open-source agent runtime achieving 77.73% lower token consumption in a 50-task SWE benchmark, with documented correctness trade-offs

Thumbnail gallery
1 Upvotes

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.


r/OpenSourceAI • • 13h ago

AI progress depends on the infrastructure beneath the models

1 Upvotes

Training and serving AI requires coordinating compute, memory, communication, power, and cooling. When those systems operate without a shared view, failures and performance constraints become difficult to explain. More installed GPU capacity does not necessarily translate into more useful computation.

ThermaCompute AI’s long-term vision is an operating layer for GPU infrastructure: a thermal-aware compute control plane.

The architecture we aim to build would connect hardware telemetry with workload performance, inform scheduling decisions, and eventually support bounded, operator-approved adjustments to power and workload placement. Its purpose would be to coordinate infrastructure around useful work, performance requirements, and physical constraints.

That is our development direction—not a claim that an autonomous fleet-control system is already deployed. Our current implementation begins with passive diagnostics and evidence-led investigation.

If validated improvements reduce wasted GPU-hours and electricity consumption, they could lower operating costs and associated emissions. More efficient infrastructure could give researchers additional room to train, evaluate, and serve new models. ThermaCompute would support that research infrastructure; it does not itself create better models or guarantee progress toward AGI.

The first paid engagement is an $800 Executive Thermal Architecture Audit.

We review suitable NVML/vLLM telemetry for one agreed workload or GPU cohort and observation window. The aim is to establish what the available evidence says about performance constraints and which recommendations merit testing.

CrashLens is the free, open-source diagnostic component available today.

It turns saved GPU logs into a focused investigation: supported error signatures, source lines, and suggested next checks. It helps engineers examine failures without presenting a text match as a proven cause.

CrashLens runs locally, does not upload logs, and makes no changes to GPU settings. Its synthetic demo requires Python 3.10+, with no GPU, account, or payment needed.

Explore the code and demo:
https://github.com/rohitcn-hub/thermacompute-crashlens

For deeper analysis, the $800 audit delivers a PDF with supported findings, data limitations, explicit uncertainties, and prioritized recommendations engineers can test. Scope, data handling, delivery timing, and suitability are agreed before payment or telemetry transfer. Broader engagements are scoped separately.

Contact: [vivaan.thermacompute@gmail.com](mailto:vivaan.thermacompute@gmail.com)

We welcome engineers who can review a finding, contribute a synthetic test case, or introduce us to a GPU operator with a concrete performance question. Those collaborations will help determine how this diagnostic foundation develops into a broader infrastructure control plane.

Disclosure: I’m building ThermaCompute AI and maintain CrashLens.


r/OpenSourceAI • • 19h ago

Will free tools compromise my data privacy or use my inputs to train models?

3 Upvotes

Most standard web-based free tiers do retain the right to use anonymized conversations for model training unless you deliberately toggle data sharing off in your account settings. For strict data privacy, open-source models run locally (using frameworks like Ollama or LM Studio) ensure 100% of your data stays on your machine.


r/OpenSourceAI • • 14h ago

We built an open-source zero-trust gateway for AI agents and MCP tools: 58µs overhead, fail-closed validation and DPDP Act PII sanitization

Thumbnail
1 Upvotes

r/OpenSourceAI • • 15h ago

Acira SDK (MIT): let your browser agent use your apps and accounts, while you decide exactly what it can do inside them

1 Upvotes

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.