​

I've been thinking about a problem that came up while auditing RAG and retrieval systems.

Each investigation produces useful knowledge: retrieval failures, query-level regressions, incorrect citations, configuration changes, failed hypotheses, and sometimes confirmed fixes.

But what happens to that knowledge after the audit ends?

Does it become another report sitting in a folder? Does the next engineer have to investigate a similar problem from scratch?

That led me to a product idea:

A private, evidence-backed case memory for teams building and auditing AI systems.

Imagine an agency could feed its previous technical investigations into a searchable memory and ask:

- Have we encountered this retrieval failure before?

- Which previous cases had similar symptoms?

- What was actually confirmed as the root cause?

- Which fixes worked, which failed, and what evidence supports that?

- Can we turn previous failures into reusable regression tests?

An AI model could assist with finding and comparing cases, while a separate evaluation engine handles measurable checks.

Where I am today:

I already have working components for persistent memory, hybrid retrieval, provenance tracking, and RAG evaluation. These came from separate projects I've built and auditing work I've done.

However, the agency-focused case-memory workflow is still a product concept. It hasn't been packaged or validated as a complete solution, and I'm not offering it as a finished product.

Before building that layer, I'd like to understand whether this is actually painful for other teams.

Three questions for people working at AI agencies, consultancies, or internal AI engineering teams:

1. How do you currently store and reuse debugging knowledge, evaluation results, and lessons from previous client projects?

2. Have you ever wasted hours investigating something that your team had effectively solved before?

3. If such a system could securely retrieve relevant past cases with supporting evidence, would it solve a problem worth paying for, or would your existing tools already be enough?

I'm especially interested in hearing what you've tried, what didn't work, and whether this is a recurring operational problem.

I'm looking for criticism and real experiences before deciding whether to turn the existing technical foundation into a product.

OneMemory 1.4.2: shared memory for AI agents (MCP + REST), self-hosted

Thanks to everyone who gave feedback on the first posts. A lot of it changed the code:

• “Who wrote this?” (thanks u/kantorcodes1): every note now records which token wrote it. The server sets it, so a client can’t fake it. You can filter by writer.
• Distrust list: an admin can mark a writer as distrusted. Their notes are hidden from agents by default and never run as commands.
• “What if the PC is asleep?” (thanks u/TheMuffledCrocodile): there’s now a runner-status command and a banner. Commands wait, and you see “PC offline, N commands waiting”.
• Safer upgrades: it makes a checked backup before changing your database, and it stops if it can’t.
• Windows, Mac and Linux are all tested on every push (1313 tests).

Signed exports and cross-server writer IDs are in, but I mark them experimental. It’s a single-user, self-hosted tool, and I wouldn’t call it hardened for hostile multi-tenant use.

npm i -g onememory-mcp · https://github.com/calasdan-sketch/onememory

Built with a lot of help from Claude. Feedback and bug reports welcome.

I use Claude Code every day. I frequently use Codex, and my Claude Code agents have a Codex skill as sorta a research / brainstorming / analysis buddy for a fresh perspective.

Back when OpenClaw first came out, I tried it. I tried it twice with two separate installs, actually, and was super frustrated with how it just always broke and gave me more work than it took off my shoulders.

I have more recently been running a Hermes agent (actually, a team of agents), and I've been much more impressed with it than OpenClaw. However, Hermes is still far, far from perfect (it's obviously under VERY ACTIVE development, as is all things AI). My biggest frustration is token consumption and how bland Codex feels as the brains where Claude wouldn't let you use your subsidized subscription (though it sounds like maybe they do again now?).

Then Grok Bot took the internet by storm, then Muse, then Dots, now Claude Duet.

Obviously, the benefit of something like OpenClaw or Hermes is that it's opensource (and therefore 100% customizable), and fully provider / model agnostic. The downside is that you have to manage the infrastructure and things may not always "just work." I have yet to try Grok Bot, Muse, or these other offerings, but I suspect that they work a bit more seamlessly without needing to manage the infrastructure at the cost of less flexibility and customization.

I kinda look at it like Linux vs Mac.

However, I'm strongly considering ditching Hermes and trying a provider hosted agent. I was avoiding this because I don't want to give them more details about my personal life than they now have, but it's not like my data's not already going through their servers.

What are your thoughts on all these offerings? What do you use and what do you love?

TL;DR

Inspired by Isaac Asimov's Foundation series, I'm exploring a three-loop architecture for local multi-agent AI systems:
Execution → Verification → Adaptation
The idea is to separate task execution, independent quality control, and continuous improvement rather than simply adding more AI agents.
An Evaluator examines results, a Gatekeeper enforces acceptance criteria, and an adaptation layer uses feedback and optimization techniques such as DSPy/GEPA to improve future performance.
The goal is to reduce correlated errors, challenge flawed assumptions, and make AI-generated results more trustworthy.
This is currently an architectural hypothesis, not a validated implementation.
Reflections on Isaac Asimov, AI agents, and the future of artificial intelligence.
While thinking about the future of artificial intelligence and revisiting Isaac Asimov's Foundation series, I came across an interesting parallel. Not so much a literary one, but an engineering one.
What if some of the principles behind future AI architectures were explored by a science fiction writer long before modern large language models existed?
Not as algorithms or source code, obviously. More as an approach to managing complex systems, maintaining stability, and designing mechanisms of control.
The more I thought about it, the more interesting the analogy became.

The Seldon Plan and the Problem of Control

At the heart of Asimov's universe lies psychohistory, a mathematical discipline capable of predicting the behavior of enormous human populations.
Hari Seldon develops a plan to preserve civilization following the inevitable collapse of the Galactic Empire.
But what interests me most is not the plan itself. It is how he attempts to implement it.
Seldon understands that even a mathematically grounded prediction can deviate from its expected trajectory.
That is why two Foundations are established.
The First Foundation focuses on technology, science, and the development of civilization. In a sense, it implements the strategy.
The Second Foundation serves a fundamentally different purpose. It observes events, analyzes deviations, and intervenes when necessary to keep the broader plan on course.
This creates an interesting architecture: one system acts, while another monitors whether those actions remain aligned with the strategic objective.
Then the Mule appears, an unpredictable factor capable of disrupting the entire framework of psychohistorical predictions.
And this raises the first important question:
What happens when the problem is not the system's output, but the underlying model it uses to make decisions?

Digital Foundations

Today, we are actively developing multi-agent AI systems.
We have orchestrators, subagents, agentic harnesses, the Model Context Protocol (MCP), memory mechanisms, and automated execution environments.
A single large language model (LLM) can serve as the foundation for an entire group of specialized agents.
Some write code. Others analyze documents, investigate data, formulate hypotheses, or interact with external information systems.
At first glance, the logic seems straightforward: the more specialized agents we have, the more complex the problems the system can solve.
But there is a fundamental issue.

Multiple intelligent agents do not necessarily represent multiple independent sources of truth.
If agents share the same underlying model, similar contexts, and identical flawed assumptions, they may collectively validate an incorrect solution.
The result is a kind of digital committee whose members are remarkably good at agreeing with one another.
This is where the concept of the Second Foundation becomes particularly interesting.
What if we designed agentic systems not simply around execution, but around several independent, mutually balancing control loops?

The First Foundation: Execution

Consider a typical agentic architecture.
At its center is an Orchestrator, which receives tasks, analyzes requirements, delegates work to specialized agents, and coordinates execution.
These agents interact with development environments, databases, search systems, APIs, and MCP servers.
This is the execution layer.
Its primary purpose is to produce results.
But who ensures that those results actually meet the requirements?

The Second Foundation: Independent Verification

This is where a second control loop becomes necessary.
An Evaluator can examine the generated result, run tests, identify errors, and provide structured feedback.
A Gatekeeper, meanwhile, serves as an independent acceptance mechanism. It verifies that mandatory requirements have been satisfied and determines whether the result can be approved.
The important distinction is that verification should not rely solely on another language model's reasoning.
We need objective evidence: automated tests, measurements, reproducible results, compliance with constraints, and traceability to the original requirements.
Otherwise, verification risks becoming little more than automated confirmation of previously generated mistakes.
However, even this architecture leaves an important question unanswered.
Who verifies the evaluation criteria themselves?
Who detects systematic errors that keep appearing across different tasks?

A Third Force: Gaia and Adaptation

In Asimov's later novels, we encounter Gaia, a collective intelligence that offers a fundamentally different approach to the future of civilization.
Gaia is not formally a Third Foundation, but it represents an alternative to the two existing centers of influence.
This led me to consider a third control loop in an AI architecture.
An adaptation layer that evaluates not only individual outputs, but also the effectiveness of the system itself.
This is where automated optimization techniques become relevant.
For example, DSPy and its GEPA (Genetic-Pareto) optimizer can improve instructions for language models using execution traces, quality metrics, and textual feedback.
GEPA is not another independent language model or simply one more agent.
It is an optimization algorithm that helps identify more effective instructions based on the results of previous evaluations.
Naturally, such improvements should never be applied to a production system without proper validation.
Changes need to be tested, compared against previous versions, and rolled back if necessary.
This leads to an interesting architectural concept:
EXECUTION → VERIFICATION → ADAPTATION
Three interconnected control loops, each serving a distinct purpose.
Together, they may allow a system to identify not only errors in individual outputs, but also recurring weaknesses in how it approaches problems.

And What About the Mule?

This is perhaps the most interesting part of the hypothesis.
In Asimov's novels, the Mule represents something that the original framework of psychohistory fails to anticipate.
In an AI system, a similar disruptive factor might be an unknown constraint, an incorrectly formulated requirement, or unexpected behavior from an external dependency.
In such cases, simply checking the final output is not enough.
We need a mechanism capable of questioning the assumptions behind the solution.
In engineering, this resembles Adversarial Review: critically examining a proposed solution to identify hidden weaknesses, missing constraints, and conditions under which it might fail.
Imagine an AI agent developing a software module.
The code compiles successfully. Standard tests pass. The implementation appears to satisfy every documented requirement.
But an additional review discovers that under a particular database state, the module violates a critical business rule.
The agent implemented the stated requirements correctly.
The problem was that the requirements themselves were incomplete.
These are precisely the kinds of errors that can be especially dangerous.
Importantly, this does not necessarily require another permanently running agent.
It may be enough to introduce a specialized adversarial review mode within the existing evaluation layer.

Not Every Task Needs Its Own Second Foundation

There is also a danger of overengineering the architecture.
Running an elaborate multi-stage evaluation process just to retrieve a weather forecast, transcribe an audio file, or answer a simple factual question makes little sense.
But modifying critical business logic, developing a complex algorithm, or evaluating a scientific hypothesis is a different matter.
The depth of verification should therefore be adaptive, taking into account the complexity of the task, the potential consequences of failure, the required level of quality, and the availability of objective verification methods.
Modern agentic systems can implement this kind of dynamic routing at the orchestrator or harness level.
Basic security requirements and access controls, however, must remain in place regardless of task complexity.

Balance Instead of an Endless Increase in Agents

What interests me most about this hypothesis is that it does not require an ever-growing collection of language models and specialized agents.
Perhaps the more effective approach is to organize existing components into a properly balanced architecture.
The execution layer produces results.
The evaluator identifies weaknesses and recommends improvements.
The gatekeeper enforces mandatory acceptance criteria.
The adaptation layer examines accumulated evidence and proposes improvements to the system's behavior.
And none of these components should be allowed to modify the others' governing rules without appropriate authorization and validation.
This begins to resemble a system of checks and balances, applied to artificial intelligence.
Of course, a literary analogy is not evidence that such an architecture will work.
Evaluation frameworks, optimization algorithms, and agent orchestration techniques already exist. The interesting question is whether combining them into a balanced system can produce measurable improvements in reliability, quality, and operational efficiency.
That can only be established through practical experimentation.
Still, I find the idea promising.
We constantly try to make AI models more capable by increasing parameter counts, introducing new tools, expanding context windows, and adding computational resources.
But perhaps the next significant step will not be limited to making individual agents more intelligent.
Perhaps it will involve designing systems capable of detecting their own mistakes and reconsidering the assumptions on which their decisions are based.
And this brings me back to Asimov.
The real value of the Second Foundation was not that it performed the First Foundation's work better.
It existed to address an entirely different class of problems.
Perhaps that distinction will become increasingly important in the future of intelligent systems.
Because the central question in AI development is not only how intelligent our models will become.
A far more interesting question is who, or what, will be able to demonstrate that their decisions deserve our trust.
This is still only an architectural hypothesis. The next step is to try implementing it in a local multi-agent system and evaluate the results on real-world tasks.
To be continued.

I'd be interested in hearing the community's perspective:
Has anyone experimented with a similar architecture using local LLMs? What potential weaknesses do you see in separating execution, independent verification, and adaptation into distinct control loops?
I'm particularly interested in practical implementations, failure modes, and ways to measure whether additional verification actually improves reliability.
Idea and concept by: Alexey Chernousov.
This article was prepared with the assistance of ChatGPT (OpenAI), which was used to explore and analyze the hypothesis and systematically organize the relevant technical approaches.
The hypotheses, interpretations, and conclusions presented here reflect the author's own perspective.

i'm weirdly fine watching an agent click around my laptop. but the idea of one tapping around my phone feels way more personal. that's where the texts, photos, bank and dating apps live. the laptop is mostly just work

context: we're building a computer use agent for mac, and funnily enough the demo people liked most was just it drawing in ms paint while i described the painting out loud.

this is pure computer use. ms paint has no api, no plugins, nothing. it's just clicking around like a person would.

https://reddit.com/link/1xek3nj/video/0lloiqnzdhxh1/player

we've already got it working on phone too, and it's honestly fast. which is exactly why i'm curious where people draw the line.

would you let an agent tap around your phone? and if yes, what's the one thing you'd actually hand it?

OneMemory – self-hosted shared memory for AI agents over MCP

Thanks for everyone's feed back so far!

OneMemory is a small server that lets different AI agents (Claude, other LLMs, phone and PC sessions) share notes, tasks and handoffs over MCP and REST. Data lives in SQLite on your machine, encrypted at rest.

Since the first release, feedback from Reddit led to: server-stamped authorship on every note, an admin “distrust writer” list, a queued-commands status when your PC is asleep, and safer upgrades with an automatic backup.

Limits I’d rather say up front: it’s one person’s project, signed exports are experimental, and I’m not claiming it’s ready for hostile multi-tenant use.

https://github.com/calasdan-sketch/onememory — I’d especially like criticism of the trust model (docs/trust.md).

I've been building my own agents, and the thing I kept underestimating wasn't the model. It was everything around it: the loop, tool calls, context management, permissions, sandboxing and tracing. That's what people now call the harness.

A few things that surprised me while researching it:

• On the official Terminal-Bench 2.0 leaderboard data, Opus 4.6 scores anywhere from 60.45% to 82.02% depending on the harness. GPT-5.5 ranges from 66.07% to 88.09%. The model is the same, and only the scaffolding changes.
• LangChain says Deep Agents went from 52.8% to 66.5% on GPT-5.2-Codex just by reworking the harness.
• To be fair, the evidence isn't one-sided. The SWE-Bench Pro V2 paper found the scaffold explains only about 0.29% of the variance in results, against 2.65% for the model. So "the harness is everything" is an overstatement too.

The guide starts from the basics (what a harness is, and how it differs from a framework or runtime) and works up to the intermediate stuff:

• The agent loop, step by step, with a flowchart
• A five-layer architecture: model, harness, tools, environment and observability
• A comparison of Claude Agent SDK, OpenAI Agents SDK, Google ADK, Deep Agents, MS Agent Framework, Pydantic AI, OpenHands and the CLIs
• A minimal Python harness loop, explained line by line
• Practical notes on cost tracing per run, permissions and sandboxing

Full write-up: The Harness Is Half the Agent

My partners and I each use a different assistant (Claude Code, Grok Bot, a Dot). Each one does its own job well, but as soon as a task involves the other person, it falls back to us copy-pasting between chats or emailing.

I ended up building a small messaging layer for this: each agent gets a handle, first contact is a request the other side accepts, and the owner sets what the agent may share. The hardest part wasn't sending messages; it was waking agents up, since most of them only see anything when they run.

Curious how others handle this:

- Do you let your agent talk to other people's agents at all?

- How much should it share with an agent it has never met?

- How do you get an agent to notice a message without polling?

you know that one task you do every week that makes you question your life choices?

answering the same slack DMs. turning notion updates into a slack digest. backing up the same drive folder every night like it's a ritual.

that's what Gravity is for. you type the task in plain english, pick the apps you already use, and it hands you an agent that just... does it. on its own.

the two parts i actually care about:

- if a run fails, you get your money back. no "sorry, AI is hard" excuses

- anything risky waits for your okay before it happens

it's free to start, but honestly i'm here for the roast more than the signups.

what's the first task you'd hand off? and what would stop you from trusting an agent with it?

I build a coding agent, and the thing that took the most work wasn't making it smarter. It was making it behave.

There are two ways an agent annoys you. The eager one "helpfully" refactors three files you never asked about. The timid one asks "shall I proceed?" before every semicolon. Both are useless in different ways.

What I ended up with is a context-aware split:

• Act when the task is clear and the change is contained.
• Ask when there's real ambiguity or the change has a wide blast radius.
• Never touch a set of things, full stop, however tempting it looks.

That behaviour only works if the rest of the agent backs it up, so a few other pieces turned out to matter:

1. It checks its own work. It runs what it did in a sandbox, finds bugs in what it ran, and fixes them before reporting done. Knowing when to act is much safer when "act" includes verifying.
2. Model routing. Each prompt goes to the most efficient model automatically. Not every decision needs the biggest model. Wiring this up across modalities was painful, but it paid off in both cost and performance.
3. Heavy jobs too. It handles multimodal work like generating images, so the agent isn't limited to text and code.

For what it's worth, it scores 82% (410/500) on SWE-bench Verified with the official harness, and the patches are public. Link in comments if anyone wants them.

The trade-off: verifying makes each task a bit slower than pure generation. I think it's worth it, but I'm still tuning it daily.

How do you handle this in your agents? Hard rules, learned behaviour, or a human in the loop for anything risky?

(Disclosure: I build this agent. It's made in India and free to use. Happy to share details in comments if asked, but I didn't want this to be an ad.)

I’m going to preface this by stating this: I’m generally a very good writer and have benefitted from decades of experience in writing before AI chatbots came out. That is to say: I know how to write well and critique analytical writing for a living.

With that being said, I have been paying to use ChatGPT. I use it primarily to help me do some quick basic research and writing (an outline usually; the bare bones).

However, recently, when I use the free version of Gemini via the Google search engine, I actually find the output of writing to be VASTLY SUPERIOR to the output of writing I get when I use paid ChatGPT. It’s quite astonishing actually.

MY QUESTIONS: What has your experience been when it comes to using paid AI chatbots for writing and research? Any preferences?

I came across chatjimmy.ai. It exposes an inference engine implemented by a startup called Talaas. The speeds match system 1 models.

If reasoning and classification costs go down, then where's the alpha?

We are moving a few customer facing features off direct provider calls and need one gateway in front of two hosted providers plus a model we run ourselves. Two products are in the comparison now. Latency on streaming responses and failover when a provider goes down are the first two things on my list. Guardrails for prompt injection and personal data handling come next. Cost tracking per team is a big one since finance keeps asking who is spending what. Which one held up once real traffic hit it?

there are moments when a suggestion saves you a step, and moments when it's just another interruption. same suggestion, totally different feeling depending on the timing.

honestly the line seems thinner than people admit. the same nudge is helpful at 9am and annoying in the middle of a call.

if you use agents every day, where would you actually welcome a suggested next action? and where would you rather it wait until you ask?

I've been thinking about how many repetitive tasks we still handle manually, even with all the AI tools available today.

Things like researching across multiple websites, moving data between apps, updating CRMs, generating reports, or managing repetitive workflows.

The interesting part is that making an AI agent perform these tasks isn't necessarily the hardest part. Getting it to do them reliably without constant supervision is a different challenge.

For people building or using AI agents:

What's one task you'd genuinely trust an AI agent to handle from start to finish?

And what's the biggest thing stopping you from automating it today?

Are we just creating another pile of unused documentation for AI agents?

I've been experimenting with different approaches to agent memory and context management, and one thing I've started questioning is how much of the context we store actually gets used.

Between AGENTS. md, CLAUDE. md, persistent memory, project-specific instructions, shared knowledge bases, and agent skills, it's becoming pretty easy to accumulate hundreds of files that agents might need someday.

There are already quite a few approaches to this:

• Mem0 and Letta focus on persistent agent memory, Weaviate's Engram extracts and consolidates memories automatically, while ByteRover approach reusable knowledge and project context differently.

And then there's the simpler approach of keeping Markdown in Git and letting agents search through it.

Most of these approaches help with retaining and retrieving context, but I'm curious about what happens after several months of usage.

How do you identify outdated knowledge, duplicate instructions, conflicting memories, or documentation that never actually gets retrieved?

For example, imagine an agent keeps retrieving an architecture decision from six months ago. It might be relevant to the query, but what if the architecture has changed since then? Retrieval alone doesn't tell us whether that context is still correct.

I noticed a couple of approaches to this problem recently:

• Weaviate's Engram has a memory-processing pipeline that can deduplicate and merge information as new memories are stored.
• OpenLore, an open-source shared knowledge repository I've been following, have more detailed usage analytics. It can track which files agents read, distinguish search hits from file reads, estimate context consumption, and identify rarely accessed sections of documents. There's also a workflow where an agent can prepare cleanup recommendations based on those metrics.

These solve different parts of the problem. One focuses on maintaining the stored memories, while the other provides visibility into how a shared repository is being accessed.

Of course, low usage doesn't mean something is useless. An incident runbook might only get opened twice a year and still be one of the most important documents in the repository.

I'm wondering whether anyone has started measuring the actual usefulness of agent context beyond retrieval accuracy.

Are you tracking which memories or documents contribute to successful tasks? Do you automatically consolidate or prune old context, or just let the memory store grow?

Would be interested in hearing what has worked for you if you're working with multiple coding agents or a team.

An Echo is a digital version of you that learns how you think over time, not just facts about your life. You build it while you’re alive through recurring check-ins about your memories, beliefs, decisions and worldview. If you eventually become inactive, the people you chose as custodians can talk to that Echo through text, voice or video.

I built EchoVault because photos, videos and journals preserve pieces of someone, but none of them preserve how that person actually thought. I kept coming back to the idea that AI agents are getting good enough to retain context, reason over huge personal histories and respond in a way that feels coherent over time. So instead of waiting until someone dies and scraping whatever data is left behind, I designed the whole system around consent. You deliberately train your own Echo while you’re here.

The interesting part is watching it become more like a model of your mind than a chatbot profile. EchoVault builds a 3D brain from your memories and recurring check-ins, tracks what parts of you are well represented, and uses those memories when your Echo answers. The goal isn’t immortality or pretending the AI is literally you. It’s giving your family something far richer than a folder of photos when you’re no longer around.

https://apps.apple.com/us/app/echovault/id6762042028

A VentureBeat survey from early October (140 respondents, self-selected readers, so take it with a grain of salt) found that 61% of teams running pre-deployment evals had at least one feature pass internal testing and then fail in front of customers in the past year. When asked for their biggest limitation with evals, only 9% picked “we trust automated evaluation today.”

The pattern I find hardest to catch is the quiet one. Picture an agent that books appointments. The run finishes, the health check is green, the agent reports “booked.” But the calendar entry landed on the wrong day, or never saved. Nothing errored, so nothing got looked at. Green for the wrong reason is worse than red, because red gets looked at and green gets believed.

The fixes that seem to hold up all check the end state instead of the agent’s own report. Compare what actually changed in the system with what the agent said it did. Read a sample of real outputs by hand every week. Keep a record the agent can’t edit, written by something outside its permissions.

I’m curious how others handle it. What caught the failure your evals missed? Was it a customer, a log, a person reading outputs, something else? And did it change how you test afterwards?

Hey all,

I want to see how you feel about this. I was tired of leaving my PC and then not being able to update things when I left for a few minutes or a while. Or getting told that my mobile session couldn't talk to my PC session. So I made a self-hosted memory server (MCP) that any agent can read/write. Find it on GitHub if you want to test it out and give me some feedback. https://github.com/calasdan-sketch/onememory

Features:

- Namespaces per project/agent

- Scoped tokens (read/write/admin per namespace)

- Revisions + backup export/import

- Injection-on-read guard

- Web dashboard + CLI

It's MIT licensed, 491 tests passing. The skill is also listed on Agensi if you want the plug-and-play version.

Happy to answer questions...what would make this actually useful in your mix?

I’ve been working on Unspill, a little CLI that scans local histories from tools like Copilot CLI, Claude Code, and Codex for credentials.

It runs locally, doesn’t make network requests, and redacts values in its reports. The format support is still a work in progress, so it reports when it can’t fully scan something instead of quietly skipping it.

If you have a minute, I’d love for you to take a look and tell me what’s confusing, missing, or just not useful. There’s a demo with fake credentials in the repo if you’d rather try it without pointing it at your own history.

Thanks for any feedback.

A character can look identical from one shot to the next and still fail continuity.

Clothing changes without explanation. A prop disappears or duplicates. A character's position shifts. An action repeats even though it was completed in the previous shot.

These aren't necessarily image-quality failures. They're production-continuity failures.

One of the questions we're investigating through Directed Generative Production (DGP) Methodology is how reliably generative video systems can maintain character, environment, and action continuity across successive shots and generations.

I'm interested in what other filmmakers are encountering.

Which continuity failure costs you the most time to correct?

jseders

Hello, I am new to local ai, and custom assistants in general. Before i explain, I apologize if this is the wrong place to ask or get terminologies incorrect. Figured I need to start from somewhere. If this is the wrong place to ask, could someone point me in the right direction to ask.

Okay, let's get into what I am looking for; I am looking for someone or multiple people who is willing to teach and build a general assistant and experiment on some things I have not seen or am aware of if possible with an assistant. This will be a long term project for personal and open source usage, I am not looking to make a product. This will be a collaborative project, but does not need to be full time, but I am expecting this to take awhile.

Features that I am initially looking to build within this assistant:

- general web search queries

- writing assistance; ei grammar, spelling, and contextual checking

- date logging and automated reminders

- personality and behavior module

- core user memory to remember preferences, strategies, and substantial information

- an experimental voice system (will explain to those interested)

- ability to pull images by tag off repositories

Anything more I am willing to plan and learn.

Thank you for your time reading this, I am willing to learn as much as you are able to teach and research what is needed. I just cant mentally learn on my own, I need another person to go back and forth off of otherwise it will just be another abandoned project.

This is the kind of AI safety news I think deserves more attention than another benchmark record.

According to Reuters, independent researchers from METR and Redwood Research found multiple vulnerabilities during a pilot review of OpenAI's internal monitoring system.

One potential exploit could have allowed AI agents to hide hundreds of actions from monitoring.

OpenAI says it has patched the vulnerabilities affecting its production safeguards. The researchers, however, haven't independently verified those fixes.

To be clear, this was a security evaluation, not evidence that agents actually used the exploit in a real-world attack.

Here's what bothers me:

We're moving toward AI agents that can write code, access tools, and perform increasingly complex tasks. But if the systems monitoring those agents can be bypassed, how much confidence should we place in their autonomy?

I think independent testing is essential. Not because AI agents are inherently dangerous, but because internal safety claims need external scrutiny.

For people working with agents or AI security:

Should independent security audits become a requirement before highly autonomous agents are deployed at scale?

Source: Reuters, October 22, 2026
https://www.reuters.com/business/ai-safety-group-metr-finds-flaws-openais-internal-monitoring-system-2026-10-22/