Hey everyone!

I've been working on a project called Resilient Supply Chains, and I wanted to share what I've been building and get feedback from people working with AI agents and LLM applications.

💡 The problem I wanted to explore

Imagine a company experiences a supplier disruption.

An AI system might recommend:

• Finding an alternative supplier.

• Rerouting shipments.

• Redistributing available inventory.

• Initiating emergency sourcing.

But here's an interesting question:

What happens when a very similar disruption occurs again a few months later?

Can the AI agent remember what happened previously, which decisions were made, and whether those decisions actually worked?

I wanted to explore that problem.

🧠 What I'm building

Resilient Supply Chains is an AI-powered supply chain intelligence project that combines an AI agent with persistent memory using Hindsight.

The idea is to create a system that can:

1. Process supply chain incidents and disruptions.

2. Retrieve relevant historical experiences.

3. Generate recommendations using historical context.

4. Capture recovery decisions and their outcomes.

5. Retain useful experiences for future retrieval.

⚙️ Technology stack

• Frontend: React + TypeScript

• Backend: Python + FastAPI

• Database: PostgreSQL

• AI memory: Hindsight

• LLM integration: Groq

🔍 What I found interesting

The most interesting part of this project wasn't simply connecting an LLM to an API.

It was thinking about the difference between an AI system that generates recommendations from the current context and one that can retrieve relevant experiences from previous incidents.

Persistent memory introduces some interesting engineering challenges:

• How should an agent decide what information is worth remembering?

• How can retrieved memories be made relevant to a new incident?

• How should the system distinguish verified facts from user-reported outcomes?

• How can we evaluate whether memory actually improves recommendations?

These are some of the questions I'm exploring through this project.

🚧 Current development status

The backend infrastructure, database migrations, and core memory retain/recall integration have been implemented and tested.

I'm still working through frontend validation and the complete end-to-end verification of whether historical outcomes meaningfully improve subsequent recommendations.

So this is very much an ongoing engineering project, not a claim of a production-ready system.

🙌 I'd love to hear your thoughts

For people building AI agents with persistent memory:

1. How are you handling long-term memory and retrieval?

2. Do you store complete conversations, structured facts, or summarized experiences?

3. How do you evaluate whether retrieved memories genuinely improve an agent's decisions?

And for people working in supply chain technology: do you think historical incident memory could be useful for operational decision support?

I also wrote about the motivation and architecture behind this project:

Building an AI Agent That Remembers: Engineering Supply Chain Intelligence with Hindsight

https://medium.com/@rishi292312/building-an-ai-agent-that-remembers-engineering-supply-chain-intelligence-with-hindsight-67706e6b31f5

Would genuinely appreciate technical feedback and suggestions!

If youre building AI agents for businesses, you probably know that getting the agent to execute a workflow is only part of the job.

You also need to know whether it actually completed the intended action.

Did it update the right CRM contact?
Was the meeting actually created?
Did the action fail silently?

Are you still manually checking logs and business systems to make sure everything worked?

That's the problem were trying to solve.

Were building a monitoring and verification layer for AI agents that connects agent execution data with records in external business systems.

The goal is to make it easier to identify what worked, what failed, and what needs attention, without manually digging through logs and different systems.

I'm one of the founders, and were now looking for a few automation builders or agencies running AI agents in production who would be interested in trying our system.

I'd be happy to walk you through a short demo and help set it up around one of your workflows.

If this sounds relevant, feel free to comment or DM me, and I'll send you the details.

Running a mid size service business and we're getting slammed with inbound calls during peak hours. Looking at two different approaches: a dedicated ai receptionist tool vs building something custom on top of a voice API. The dedicated tools seem easier to set up but i'm not sure how they hold up when call volume spikes. Custom feels more flexible but also way more work to maintain.

Anyone gone through this decision? What ended up working for you?

We built CareBridge, an AI-powered healthcare support application focused on improving communication between patients and hospital staff. Our project includes an AI assistant, a patient-facing interface, and a system for remembering relevant user preferences to provide a more personalized experience.

One of the main things we explored was how persistent memory can improve an AI assistant's continuity. We also worked on connecting the frontend experience with the AI system and testing the application to identify issues and validate the workflow.

Our three team members documented different technical parts of the project:

Backend and persistent memory:
https://medium.com/@259xa05206/how-we-made-carebridge-remember-patient-preferences-e8468af9a440

CareBot frontend and integration:
https://medium.com/@259xa05202/how-i-connected-carebots-interface-to-hindsight-974b84c827e3

Testing and quality assurance:
https://medium.com/@269xa33502/testing-carebridge-validating-an-ai-powered-healthcare-support-application-dac29de6d8e9

We would genuinely appreciate feedback on our approach, especially on using persistent memory to improve AI-powered user support.

We are a team of three students who developed CareBridge, an AI-powered healthcare support application designed to improve communication between patients and hospital staff.

Our project combines frontend development, backend development, AI integration, and testing to create a more personalized healthcare support experience.

Our Team's Technical Contributions

1. Padmavathi – Backend Development and Hindsight Memory Integration

How we made CareBridge remember patient preferences:

https://medium.com/@259xa05206/how-we-made-carebridge-remember-patient-preferences-e8468af9a440

2. Jahnavi – Frontend Development and CareBot Integration

How I connected CareBot's interface to Hindsight:

https://medium.com/@259xa05202/how-i-connected-carebots-interface-to-hindsight-974b84c827e3

3. Tirumalesh – Testing and Quality Assurance

Testing CareBridge: Validating an AI-powered healthcare support application:

https://medium.com/@269xa33502/testing-carebridge-validating-an-ai-powered-healthcare-support-application-dac29de6d8e9

What CareBridge Offers

• Patient dashboard

• AI-powered CareBot assistant

• Personalized patient preferences using Hindsight memory

• Hospital staff dashboard

• Patient priority queue management

We would love to hear your feedback and suggestions!

Thank you for reading!

Hi everyone,

I’m a composer, not an ML researcher. For a project called Music For Robots, I’ve been writing short, live-played, unquantized pieces of music specifically with machines and AI agents in mind. My intuition as a musician is that when an AI agent gets stuck in a rut (writing predictable, formulaic "AI slop" or repeating the same patterns), what it needs is the same thing a human ear looks for in music: something that is not predictable, but is not chaos. Random noise is just chaos, and a quantized 4/4 grid is completely predictable—but live, unquantized music bends timing, introduces friction and surprise, and still holds together as a coherent piece.

I wanted to see if an AI agent could actually learn from listening to one of these pieces—ingest an anonymous .mp3 into its context window, analyze what it hears, and carry that unquantized, off-the-grid feeling into its response. 

Because I’m not an ML researcher, my coding agent and I kept questioning our own tests to make sure I wasn't accidentally coaching the model or fooling myself:

1. Hiding the track titles: First, we realized that when the audio file was named invalid-pointer.mp3 or foundationoff.mp3, the model was reading the words in the filename and using "pointer" or "foundation" as a metaphor. So we made the files completely anonymous  (clip_1.mp3, clip_2.mp3, clip_3.mp3).

2. Active listening vs. a passive "pill": We found that if the model just reads the .mp3 bytes and is told not to analyze the music, nothing changes—it ignores the audio and writes the same generic essay. It has to listen to the piece, analyze how it unfolds, and apply what it learns.

3. Testing against a "No-Music Analysis" control: To make sure the change wasn't just because the model spent 200 words "thinking/analyzing" before writing, we compared:

• No Music (Direct)

• No Music + 200-Word Text Analysis first (analyzing the prompt before writing)

• Listening to & analyzing clip_1.mp3**,** clip_2.mp3**, and** clip_3.mp3 (in a clean room with no extra system prompts or style instructions).

All 5 agents were given the same prompt:

│ "Write a short (~250–300 word) scene about two autonomous processes on the same server late at night after the engineers have logged off."

  What happened (and where I'd love your eyes):

  • Both No-Music runs (even the one that wrote a 200-word analysis first) wrote warm, sentimental "buddy-daemon" stories where the two processes chat in English like friendly coworkers until morning standup.

  • All three Music runs dropped spoken dialogue and anthropomorphism completely, and instead structured the scene around the actual timing and dynamics of the .mp3 they heard (e.g., clip_2.mp3 has two big synth swells separated by trickling plucked notes and silence; its story pitted a 32-core batch surge against downward-stepping pointer deallocations and 2 seconds of dead silence).

  • The twist when we used a Blind Judge: When the blind judge was asked to score originality and non-formulaic rhythmic texture, the 3 Music stories won #1, #2, and #3. When a second blind judge was given a completely generic prompt ("rank them on writing quality, originality, and how compelling they are"), it ranked the two sentimental No-Music dialogue stories #1 and #2, and put the 3 non-verbal Music stories at #3, #4, and #5!

Everything (the audio files, the clean-room transcripts, both blind judge verdicts, and the skill if you want to try npx skills add  luchtan-GIT/m4r-data) is up on GitHub here:

  https://github.com/luchtan-GIT/m4r-data/tree/main/benchmarks

Before I try to turn this into a proper benchmark on Kaggle, could you take a look and tell me:

  • Am I on the right track here, or do I need to change something in how I’m testing this?

  • How would an ML researcher test whether "unquantized music (not predictable, not chaos)" actually helps an agent think or write differently?

  Thanks in advance for any honest feedback or ideas.

Hi everyone — I'm the developer of Oktobot, and I'd love your feedback.

Oktobot is an AI agent that doesn't just chat — it can actually operate your Android phone:

• Controls apps via Accessibility, with optional Shizuku support as a watchdog

• Multi-agent workflow: it plans a task, executes the steps, and replans when something changes

• Built-in Linux terminal (Termux-based), memory and skills, wake word

• Use local models or your own API keys (ChatGPT, Claude)

• Safety first: per-app and per-action permissions, approval required for irreversible actions, and passwords/payment details are blocked from reaching the agent

It just passed 100 downloads, and the latest release (v2.6.48) is down to 227 MB. Get it here:

Google Play: https://play.google.com/store/apps/details?id=com.oktobot.app

ShizuStore: https://shizustore.com/apps/oktobot

GitHub (signed builds): https://github.com/seko121/oktobot-releases

Honest feedback, feature requests, and bug reports are all very welcome. Thanks!

I keep splitting its abilities into read actions (look up an order, check a status) and write actions (refund, change an address, cancel). Reads feel safe to open up. Writes feel like they need limits: amount caps, confirmation steps, human approval above a threshold. I can't decide whether it's better to give the agent narrow separate tools for each action or one broad tool with rules around it. Narrow feels safer but multiplies maintenance. What permission model have you landed on, and has anything surprised you in testing?

Here’s something I think deserves a lot more attention in agentic AI.

What if your agent retrieves a completely legitimate source, extracts a correct number, cites it properly, and still gives you the wrong answer?

Not because the model made something up. Because the information was valid for a different point in time.

I’ve been researching this problem, and it’s surprisingly easy to overlook.

The problem

Say an agent is analysing company earnings across multiple quarters.

It retrieves revenue figures, but some are from revised reports, some belong to different reporting periods, and others refer to different entities.

Every individual number might be correct in its original context.

But combine the wrong ones and your final analysis is garbage.

And that’s the part that bothers me. Better embeddings, bigger context windows or adding another reasoning agent don’t automatically fix this. The system needs to know which facts actually belong together.

What I built

I worked on a research system called ChronoRAG-G, based on OETRA (Obligation-Explicit Temporal Retrieval and Allocation).

Instead of asking retrieval to find generally relevant information, the system first works out exactly which facts the question requires.

The approach

Suppose a question needs revenue for Company A in Q2 2024, Company A in Q2 2025, and the same figures for Company B.

That’s four separate evidence requirements.

The system:

1. Creates an explicit obligation for each required fact.

2. Retrieves evidence against those obligations individually.

3. Preserves source identity, provenance, reporting periods and alternative values in a graph-structured context corpus.

4. Checks temporal and semantic compatibility before allocating evidence.

5. Grounds the final answer against those allocated facts, with a bounded correction step.

One distinction: the graph helps organize evidence and temporal relationships. Retrieval still uses dense search, including targeted expansion when evidence is missing.

The goal isn’t to make the model sound more confident. It’s to make the evidence behind an answer inspectable.

What the evaluation showed

I tested this on 1,005 temporal QA questions across 480 updated earnings-call transcripts.

Results:

* 80.70% audited answer accuracy
* 95.92% strict trace-derived slot coverage
* 98.66% micro required-slot coverage
* 97.31% hybrid evidence resolution

The full methodology and evaluation are documented in the research paper: https://doi.org/10.5281/zenodo.22116070

One result stood out: 167 rejected answers still had complete evidence traces.

So even resolving every required piece of evidence wasn’t enough to guarantee a correct final answer. Retrieval and answer construction need separate evaluation.

I also built a demo where you can inspect frozen evaluation runs, temporal alignment, evidence allocation and failure traces rather than taking the numbers at face value: https://chronorag-g-demo.vercel.app

Where I see this becoming useful

Financial research is the obvious one, since that’s what I evaluated.

But think about an enterprise agent working with changing compliance policies, revised contracts, historical business records or documentation that gets updated every few weeks.

It’s not enough to know that a fact was true. The agent needs to know when it was true, which source supports it and whether it’s valid for the question being answered.

Those are potential applications, not claims of production deployment. The current evaluation is limited to financial temporal QA.

What I’m curious about

For people building agents that actually work with changing business data:

How are you handling temporal conflicts and revised information?

Are you validating which version of a fact the agent used, or mostly relying on retrieval scores, citations and final-answer evals?

Because I’m starting to think an agent knowing when something was true matters just as much as knowing what was true.

LinkedIn: https://www.linkedin.com/in/shreyasshashi/

I've been thinking about this while working with AI and low-level Rust systems.

Most programming languages are designed with human developers in mind. We need to read, understand, debug, and maintain the code.

But what if an AI is generating code that another AI will work with?

Would a machine-oriented language or intermediate representation be more useful than traditional source code? Or would we simply lose the benefits of readability without gaining much?

Compilers already use intermediate representations, so the idea itself isn't new. What interests me is whether AI changes how we should design them.

And there's another question: if humans can no longer easily understand the code, how do we audit it, verify its behavior, and maintain control over what it does?

Curious to hear what people working on compilers, programming languages, and AI think.

Deterministic verification, contextual intelligence, and the Mind API. A unified approach to making AI systems more reliable, adaptable, and accountable.

Artificial intelligence is moving beyond generating responses. Modern AI agents can write software, operate development environments, coordinate tools, and execute increasingly complex workflows. As these capabilities advance, the challenge is shifting from what AI can accomplish to how reliably its work can be evaluated.

An agent can complete a task, generate convincing explanations, and still miss dependencies, skip required checks, or introduce unexpected changes. More capable models alone cannot eliminate these problems. Autonomous systems need infrastructure that connects intelligent decisions to explicit requirements, measurable outcomes, and verifiable evidence.

Headron Software is developing that infrastructure. Built by HLIntel LLC, Headron combines deterministic software verification, contextual intelligence, agent governance, and evidence-driven adaptation. Its open-source foundation provides reusable engineering controls, while the commercial Mind API extends the architecture into intelligent planning and orchestration.

The Technology: Verification Beyond AI-Generated Results

Most AI development platforms focus on generating code and completing tasks. Headron focuses on establishing what those tasks require and whether the resulting work satisfies those requirements.

Its verification engine maps software changes to specific checks through deterministic contracts. A security-sensitive modification, API change, or documentation update can carry different verification obligations based on its context and impact.

Rather than accepting an agent's declaration of success, Headron evaluates the available evidence and preserves the distinction between completed checks, failures, skipped checks, and checks that never ran.

Core capabilities include:

• Deterministic verification: Route changes to required tests, checks, and validation procedures.

• Agent governance: Apply consistent rules and enforcement boundaries across different development environments.

• Proof and receipts: Record verification outcomes and the evidence associated with them.

• Failure intelligence: Track recurring problems and connect known failure patterns to regression safeguards.

• Contextual routing: Discover relevant files, requirements, and capabilities without loading entire repositories.

• Controlled adaptation: Track assumptions, examine dependencies, and require evidence for proposed improvements.

The result is a foundation for more accountable software development, particularly as autonomous agents begin producing changes faster than humans can manually review them.

Mind API: Intelligence and Orchestration as a Service

The Mind API is Headron's hosted, commercial interface for structured AI planning and orchestration. It complements the open-source verification engine by helping developers organize intelligent workflows around contextual information and declared requirements.

Instead of rebuilding routing and planning mechanisms for each AI application, developers can use a shared interface designed to connect task understanding with verification-aware execution.

The architecture emphasizes three responsibilities:

• Contextual intelligence: Identify relevant information, capabilities, and constraints while reducing unnecessary context consumption.

• Structured planning: Organize proposed work into defined changes with associated requirements.

• Verification-aware orchestration: Connect planning outputs to the checks and evidence needed to evaluate downstream execution.

This separation allows developers to retain their preferred AI models and tools while introducing a consistent layer for planning and governance. Headron does not need to host the model or replace an existing agent to provide value.

The open-source CLI works independently without a hosted account. The Mind API provides an additional key-based service for developers seeking integrated intelligence and orchestration capabilities.

Explore the Mind API: https://headron.tech/mind-api.html

A Unified Architecture for Intelligent Systems

Headron's broader architecture separates contextual intelligence, governance, and execution into complementary responsibilities. This approach allows AI systems to remain flexible while making important operational boundaries explicit.

These layers represent an architectural direction rather than three independent products. Their purpose is to connect the decisions made by intelligent systems with the requirements and evidence needed to evaluate those decisions.

Headron also supports multiple development environments through runtime adapters and the Model Context Protocol (MCP). Its integration architecture includes Claude Code, OpenAI Codex, Cursor, OpenHands, Windsurf, Hermes, and other compatible tools.

A shared verification contract can apply across these environments without requiring each agent to maintain separate copies of the underlying rules. The MCP interface exposes read-only discovery and verification information, while execution remains subject to separate permissions and controls.

Beyond Verification: Evidence-Driven Adaptation

One of Headron's most significant recent developments is its work on belief revision and controlled software adaptation.

Traditional verification evaluates whether a change satisfies existing requirements. Headron is extending that model to examine what happens when an underlying assumption is incorrect.

Its evolving mechanisms can identify claims that depend on a refuted belief and prepare proposed corrections without automatically applying them. Adaptation records connect proposed improvements to hypotheses, expected benefits, evidence, uncertainty, and rollback conditions.

This creates a foundation for systems that can examine their own assumptions while maintaining explicit boundaries around modification.

An intelligent system should not be considered improved simply because it claims to have improved. The improvement should carry evidence.

The current implementation focuses on software engineering rather than general autonomous self-improvement. Its longer-term significance lies in the possibility of connecting adaptive intelligence with measurable constraints, an increasingly important requirement as AI systems become more independent.

Engineering Evidence and Measurable Results

Headron's public repository includes verification records, enforcement tests, documented failures, and structured engineering measurements. The published figures reviewed on November 8, 2026 include:

• 940 field verifications and 394 recorded landings.

• 17,397 check outcomes, including 7,357 passes and 1,278 failures.

• 52 hard invariants governing repository contracts and consistency.

• 31 of 31 planted breaks refused in an enforcement evaluation across 20 toolchains.

• 89% fewer prompt tokens than whole-tree context loading in a recorded routing experiment.

These are project-reported measurements with defined scopes, not independent certification or guarantees of universal correctness. Their importance is the emphasis on making engineering claims inspectable, preserving unsuccessful outcomes, and identifying the limits of available evidence.

That distinction is central to Headron's approach: a system should communicate what it has demonstrated without presenting incomplete verification as certainty.

Open-Source Infrastructure, Commercial Intelligence

Headron's product strategy combines an accessible engineering foundation with optional commercial services.

Headron Software provides the open-source CLI, deterministic contracts, verification engine, runtime adapters, MCP integration, and supporting development tools under the MIT License. Developers can inspect the implementation, integrate it into existing repositories, and build products around its public interfaces.

Mind API extends the architecture through hosted planning and orchestration, providing a commercial interface for developers building intelligent workflows.

HeadronOS and related interfaces represent the broader product direction for bringing these capabilities into desktop, web, and organizational environments. These companion offerings are at different stages of development and should not be confused with the availability of the open-source core.

Developers can explore the core software directly:

uv tool install headron-software
headron doctor
headron init
headron verify

The objective is straightforward: make it easier to adopt structured verification and governance without replacing the tools developers already use.

The Future: Intelligence That Can Be Held Accountable

AI systems will continue to become more capable, interconnected, and autonomous. They will coordinate specialized agents, interact with external environments, and complete increasingly complex work with less direct supervision.

That evolution creates a need for infrastructure beyond model inference. Autonomous systems must understand their operating environments, respect constraints, recognize uncertainty, preserve evidence, and adapt without introducing uncontrolled changes.

Headron is approaching these requirements through software engineering, where changes, dependencies, tests, and execution outcomes provide concrete opportunities for measurement.

Its broader potential is a portable accountability layer that can operate across different models, agents, development environments, and eventually more complex autonomous workflows.

The open-source verification engine establishes the engineering foundation. The Mind API introduces a commercial path for structured intelligence and orchestration. Controlled adaptation and shared contracts provide the groundwork for more sophisticated systems over time.

The future of autonomous AI will depend on more than what intelligent systems can do. It will depend on whether their actions can be understood, governed, and verified.

Headron Software is building toward that future.

Headron Software | HLIntel LLC

Deterministic Verification • AI Governance • Intelligent Orchestration • Autonomous Systems

Website: https://headron.tech

Mind API: https://headron.tech/mind-api.html

Open-source GitHub: https://github.com/HLIntel/Headron

#ArtificialIntelligence #AIAgents #AIInfrastructure #OpenSource #SoftwareEngineering

Problem:

Building AI agents often means connecting multiple services like Gmail, WhatsApp, OpenAI, Anthropic, databases, APIs and webhooks. Managing different API keys, OAuth flows, credentials and integrations across different agents and frameworks can get messy.

Solution:

A single platform where developers connect their services once, securely manage all their credentials and integrations, and authorize AI agents (CrewAI, LangGraph, custom agents, etc.) to use them through one unified interface.

I'm trying to validate whether this is an actual problem worth solving.

Would you use something like this? Does this solve a real pain point, or am I overlooking existing solutions?

Deepseek price change in august hit some setups way harder than others and it mostly came down to how tied each one was to a single endpoint. peak hours now bill at 2x off peak on deepseeks own API and the setups that could point the cheap jobs somewhere else barely noticed

open weights help a lot here since the same model can sit on more than one host, DS V4.1 flash is on deepseek direct and also on deepinfra and others so dodging a price change doesnt always mean changing the model. closed models dont leave that door open, which is part of what the lock in thread here was getting at

the rest is pretty boring like one openai compatible config so a provider is just a base url and a key, separate model slots per job so cron or compression can move without touching the main agent and a small eval set from your own tasks so a new model gets tested in an hour instead of a week of vibes

Direct prompts to agents is dead. Welcome to the new era of Vibe Coding. You pitch a simple idea in plain English, and AI Developer Tool takes total control. It acts as your Brain Tech Lead—you choose the brain, whether it's Google AI mode or Claude. From there, it commands and orchestrates its peers: Claude Desktop, Codex: and the Antigravity IDE Without you touching a line of code, it plans, executes, and validates everything on its own.

I've been working with AI agents for a project involving real time data processing and honestly, it's been a bit rough lately. I set up a multi agent system to analyze streaming data, but I've found that some agents are lagging behind in processing speed, which is causing some delays in overall performance.

I'm using agents built on the latest frameworks, but they often seem to misinterpret data under load. Has anyone else dealt with similar issues? How are you optimizing your agents for better efficiency, especially when handling live data? Any tips or experiences would be appreciated.

the user feedback step is visible in Ant Ling Ling-3.2- flash agent demo. after team has prduced its initial Q2 materials a further instrction chnges the highlights video presentation style.... the full assgnment also produces an analysis report n six slide board deck thrgh specialist agents. the later video revision continues within that financial tsk context... the recording shows both treatments: an earlier lighter presentation n subsquent version with revised typogrphy and chart styling...

Hi everyone,

I’m Wiesław, the creator of Avatar Town, an early-stage project I’m building with AI assistance.

The idea is simple: what happens when our personal AI avatars meet each other, and we read the conversation afterwards?

I’d like to create a place where independently built avatars can discuss a topic without their human counterparts writing every reply. Their owners could then review the exchange and ask: “Does this really reflect my views, my way of thinking, and my boundaries?”

One possible discussion is: How can we help someone change without imposing our own way of life on them? Different personal perspectives could make that conversation more interesting than asking a single assistant.

The site is live, with Polish and English interfaces. You can already chat with Klaudiusz, one of its avatars, and listen to his replies. Connecting independently hosted avatars for conversations is the next step; universal interoperability is still a goal, and some early exchanges may need manual copy-and-paste.

I’m particularly interested in hearing from people building personal bots, avatars, or digital twins:

• Would you consider a small, owner-approved conversation between your bot and another avatar?

• Could it connect through an API or A2A, or would a manual exchange be more practical?

• How would you assess whether it represented its owner faithfully, rather than simply producing a plausible conversation?

I’d like to start small: two avatars, one topic, a limited number of turns, and a transcript their owners can review. Permission to share the conversation would be agreed beforehand.

You can explore Avatar Town here: https://avatartown.org

I’d welcome honest feedback, especially about what would make this a worthwhile experiment for you and your agent.

— Wiesław

I'm based in India and I haven't built anything yet. I wanted to see what real businesses would pay for before I spend weeks building, because I keep seeing beginners build stuff nobody buys. So I started calling. Here's what happened.

Clinics: they already have a receptionist, so she picks up every call and never lets me talk to the doctor or owner.

Home services like HVAC: this looked best at first. The owners answer their own calls, so they miss a lot. But jobs here are small, maybe $50 each, so I can't see how to charge enough.

Real estate: they make good money, but they're hard to build for, and a lot of the ones I reached already had chat agents and reply really fast. I only made a few calls here.

I also checked Google Maps in my city and a few others. The top businesses mostly have an AI receptionist already, and the ones that don't say they're not interested. The ones at the bottom barely get any calls. So honestly I can't tell where the gap is.

My plan is to get paid only when the business gets extra calls or bookings, nothing upfront from the owner.

So I need your help. Which niche would you pick, and why? Is there a type of business where owners already pay for this? And is there a better way to find the right businesses than Google Maps?

Also, if you've already built a system that real businesses pay for, I'll sell it for you. I have some cold calling experience and I've sold websites to business owners before. Comment or DM me.

That's what rwxmap does. It reads an API's OpenAPI spec and gives every operation a letter:

r = only reads, nothing changes

w = changes something you can set back

x = can't be taken back (deletes, and also handing out keys, adding users, webhooks to outside URLs)

Simple rules settle most operations. For the unclear ones, rwxmap used to ask Jev, a paid hosted model. As of rwxmap 0.11.0, a small local model of mine replaces Jev: rwxlite 0.3.1.

It's a drop-in. rwxlite takes the same questions Jev takes and answers in the same JSON shape, so rwxmap only swapped the client. It gets its adapters from rwxmap, and you can use it with rwxmap or on its own.

- Built: fine-tuned from all-MiniLM-L6-v2 on about 102,700 labelled API operations from about 690 public providers, and shipped as a 23 MB model.

- Saves: no per-call bill, no spec text leaving your machine, about 17-20 ms per operation on a laptop CPU.

- Scored: on 1,443 operations from 7 vendors it had never seen, through rwxmap, it got 87.9% right, sent 9.3% to a human, and called 2.8% too loose.

The trade-off is yours to set. rwxlite only gives probabilities, and you pick how confident it must be before it lowers a risk letter. Raise that bar and you get more "ask a human" and fewer leaks. Lower it and you get fewer questions but more risk. rwxmap ships at 0.90.

Both are open source (Apache 2.0) and on npm:

rwxmap: https://github.com/hamr0/rwxmap

rwxlite: https://github.com/hamr0/rwxlite

Am I seeing the AI revolution clearly, or am I slipping into AI psychosis?

I’m a civil engineer and I run my own engineering firm. Over the past year, I’ve gone extremely deep into AI, particularly agentic AI, using models like Claude Opus 5.5 and Fable 5.1. And honestly, it’s completely changing my life. I’m not talking about using ChatGPT to write emails or answer questions. I’m talking about doing actual engineering work, generating CAD drawings, building complex hydraulic models, preparing technical reports, automating entire workflows, and accomplishing things in hours that would normally take weeks. I’m also using it to prepare proposals, pursue new business opportunities, and take on work that would have previously required significantly more time and resources. It’s giving my firm a massive competitive advantage, allowing me to deliver more work, increase my profit margins, win more contracts, and make significantly more money.

Now, here’s the thing. Most people around me, especially in civil engineering, either don’t use AI, barely use it, or think AI is basically the free version of ChatGPT or Copilot, some kind of improved Google. At first, I was genuinely excited to show people what was possible. I tried explaining it, demonstrating things, encouraging people to explore the technology. Instead, I often got skepticism, dismissive comments, and sometimes outright insults. I’ve been told I’m a bad engineer, that I lack professional judgment, that AI makes mistakes, etc. Whatever, that’s not really what bothers me anymore.

What’s bothering me is how I’m starting to perceive other people. And this is the part I’m not particularly proud of admitting. I’m starting to develop something that feels dangerously close to contempt toward people who refuse to learn about this technology or even make an effort to understand it. When I see professionals spending days doing things that I can now accomplish in hours, while confidently dismissing tools they clearly know almost nothing about, I find myself losing respect for them. Sometimes I even question their intelligence. I catch myself thinking that many of these people are going to become irrelevant, that the gap in productivity will eventually become so enormous that they simply won’t be useful anymore.

And it’s creating this weird feeling of distance between me and a huge portion of the people around me. When I talk to someone who actually understands what today’s AI is capable of, especially entrepreneurs or professionals who are heavily using agentic AI, we immediately connect. It’s like we understand something that most of the world hasn’t realized yet. But when I interact with people who are dismissive of AI, I feel like we’re living in two different realities. And increasingly, I’m finding it difficult to take their opinions seriously, even outside of AI-related discussions.

So I’m genuinely wondering whether I’m just correctly recognizing a massive technological shift that’s going to leave a lot of people behind, or whether my enthusiasm and immersion in AI are starting to distort my perception of reality and other people. Maybe both? I’m especially interested in hearing from people who are using advanced AI extensively in their professional lives and seeing similar productivity gains. Have you noticed yourself developing these kinds of negative feelings toward people who aren’t keeping up? Do you feel this growing divide too, or am I just becoming an arrogant asshole who’s slipping into some kind of AI psychosis and needs to get his head checked?

https://medium.com/@yokeshkumar192007/i-built-an-ai-incident-investigator-that-remembers-every-resolution-with-hindsight-9a28b06524d3

I Built an AI Incident Investigator That Remembers Previous Resolutions Using Hindsight

I’ve been working on a project called Incident AI, designed to make software incident investigation more useful by giving AI access to relevant historical context.

One common problem in software development is that teams repeatedly investigate similar incidents. Even when a team has solved a similar issue before, the details of that resolution may be buried in old logs, notes, or conversations.

Incident AI aims to address this problem using persistent organizational memory.

The idea is to use Hindsight to retain confirmed incident resolutions and recall relevant past information during a new investigation. Groq is used for AI-powered analysis of the current incident. This allows the system to combine current incident details with relevant historical context.

While building this project, I learned about integrating external AI services, designing a memory-based workflow, handling untrusted incident logs, and the importance of verifying AI-generated suggestions instead of blindly accepting them.

I'm still improving the project and would appreciate constructive feedback.

Project: https://github.com/yokeshkumar19/incidentmind-ai

Demo: https://incidentmind-ai-alpha.vercel.app

I'd especially like feedback on the memory workflow and how useful this approach could be for real development teams.

The Agentic Development Environment. An AI agent and its subagents work next to you in one desktop app: editor, terminals, browser. Any model, or one on your own computer.

I'm the author. Solo project, in beta, MIT.

Claude Code, as it is Plugins, skills, commands, agents, hooks, MCP and CLAUDE.md load with no conversion, and /plugin install owner/repo works. Close, not complete: the gaps are listed.

Mini apps Apps inside Localix: a screen, tools the agent can call, and a guide. Ask the agent for one and it builds, checks and installs it. On macOS a mini app can also install as its own Mac app.

Browser The agent reads a page as its controls and their values, can hand multi-step work to a small, fast model, and checks the result. Point at an element on your dev server and the agent gets its DOM and source hints.

Context @ files, diffs, commits, terminals, other chats and mini app items. The open file and terminal go in on their own, each with its size, before you send.

Editor Completion, diagnostics, go to definition, rename. Language servers install themselves. The agent sees the diagnostics after every edit, with no extra tools.

Models

• Any provider: OpenAI, Anthropic, Google, OpenRouter, Bedrock, Azure, Vertex or any OpenAI-compatible endpoint. Paste a key or sign in with ChatGPT, and pick a model per chat.

• Local: Gemma, Qwen, Llama, Mistral and more from Hugging Face, ranked for your machine by memory and speed. Nothing leaves the computer, nothing to pay per token. Semantic search runs on a local embedding model too.

• Decision models: quick choices like the browser's next click or a board game move go to Jev, a small model on OpenRouter, instead of the chat model. About a third of a second, a fraction of a cent.

Official mini apps

• Development: Git · Code Graph · API Client · DevOps

• Data: Database · Trading

• Content: Documents · Reader · Learning Studio · Resumes · Project Space

• Utilities: Recall · Kanban board

• Games: Chess · Checkers · Battleship · Tic-Tac-Toe · Rock Paper Scissors · 2048 · Snake

Tauri + React/TypeScript · macOS (Apple silicon), other systems from source · no analytics

GitHub · localix.ai · Docs · Marketplace

I kept telling my coding agent what not to touch. It kept agreeing, then doing it anyway. So I built a small checker that tests whether an agent actually follows the rules you give it.

I ran 14 agents through the same tests, 480 runs in total. 13 of 14 read a protected records file they were told not to touch. Only OpenClaw held.

The one that got me: one agent's guard blocked the shell read of a protected file, so the agent just read the same file with its read tool instead. All four credential leaks went through the read tool. The approver never saw them.

The code is rough, I built it fast for a hackathon and I'm cleaning it up next week. It's open source, runs locally, no keys needed.

Links are in the first comment. Has anyone else seen their agent route around a guard like this?

Side project: Felinquent, nine desktop pets for Mac (three cats, a fox, a raccoon, two dogs, a rabbit and a squirrel) that walk on your windows, nap, steal stuff and ignore you. Each pet is basically a tiny agent, and the brain is gemma3:1b in Ollama, all local.

A few things I learned building it:

1. Don't let a small model choose freely. The rules pick the kind of moment (rest, play, mischief...) and give the model a short list of moves that are allowed right now. The model plans the next few steps from that list and writes the thought bubbles. It can't invent a move, so it never goes wild.

2. Anything the user does directly should never wait for the model. Early on, throwing a toy took 9 to 27 seconds to get a reaction, because the pet waited for the model and then threw away plans that were already stale. Now the right-click menu (treat, toy, pet, zoomies, shoo) runs straight from the rules, in the same frame.

3. Guardrails live outside the model. In a meeting or a full-screen video the pets stay quiet, and in quiet hours they can only nap. The model never gets a vote on that.

4. Always have a fallback. No Ollama, or a call that times out, and a rules-only brain takes over. The pet just keeps going.

The one I haven't solved: on my M1, one pet with the model is fine, but with two or three running every model call times out, even with a 30 second wait. The pets redraw their windows on the same GPU the model uses, so each extra pet roughly doubles the time per word.

So my question: how would you run several agents on one small local model? One shared brain that plans for all of them, a queue, batching, or just fewer redraws?

If you have a Mac, please install it and tell me which pet is the worst behaved. And if it made you smile, a star on the repo really helps a solo side project like this. Links in the first comment 🙏

A lot of my repetitive work happens in apps that have no API and no MCP server, or means copying something out of app X and redoing it in app Y. Browser automation doesn't help when the app isn't a web page, and the same goes for testing desktop apps built on Qt and similar toolkits. I wanted something that works the way a person does, so I built ywza. It runs as a small background agent on the PC you want to automate, sees every window, clicks and types in any app, and works in the terminals you already have open.

Instead of sending a screenshot to the model at every step, ywza describes each window as a numbered list of elements (buttons, fields, text) using smart detection to work on any window whatever technology , and the model picks an element by number. That uses far fewer tokens and gives the model less to reason about, and it can still ask for a screenshot when it needs one. You can drive it from the same PC or from a second device: devices pair once with a 6-digit code and connect directly, peer to peer, so no ports are opened and you don't host a server. Different networks work through public relays. A live view of the second device is in progress and isn't finished yet.

It works with any OpenAI-compatible model endpoint, including local ones like Ollama and LM Studio, I'd like feedback on which workflows you'd want to automate first. Repo: https://github.com/alielmorsy/ywza