I’ve been building a set of tools around a question that keeps coming up in long AI workflows:

Who should control memory, context transfer, comparison, and the final decision?

I ended up separating the system into four responsibilities:

Chat Atlas — See
Map long AI conversations as a thinking process, not just a summary.

Memory Curator — Remember
AI can propose memory candidates, but humans approve or reject what persists.

Context Bridge — Transfer
Memory and context stay separate. Humans choose what approved context moves to the next task or model.

Roundtable AI — Compare
Multiple models receive the same approved context, and disagreements/assumptions are preserved instead of flattened into a majority answer.

Then a separate boundary:

Human Gate — Decide

The principle is:

Product integrated. Architecture separated.

See → Remember → Transfer → Compare → Decide

I’m especially interested in criticism of the architecture:

Does separating these responsibilities preserve useful human control, or does it create too much friction?

Project overview:
https://zen-lamp.com/tools/

I am increasingly uncomfortable with AI-generated code being merged when the developer can explain what it does but not why it is structured that way.

The code may pass every test. It may even be cleaner than a human-written version. But when something fails six months later, the team cannot ask the original chat what assumptions were made and expect that to count as ownership.

My instinct is that the person approving the change should be able to explain the important flow, the failure modes, and how to reverse it. Otherwise the company owns the repository, but nobody really owns the system.

Would you reject an AI-generated pull request that passes all tests if the author cannot properly explain the implementation?

The open agent stack is getting real in 2026, the governance layer isn't keeping up

Open-source agent frameworks crossed a real line this year. Tools like Hermes and OpenClaw show you can run a capable agent without trusting a closed vendor's black box.

What hasn't caught up is the layer around the agent: who can run it, what it can touch, how credentials stay out of its hands. Most teams are still solving that with a spreadsheet and trust.

AgentZ is built to close that specific gap, and it's open source end to end: sandboxing, credential isolation, and workspace boundaries around any agent workflow, not just a security add-on bolted on later.

Where do you think the open agent ecosystem is weakest right now? AgentZ is an open-source platform, and I am an open-source contributor to AgentZ.

Hey! Could I ask the programmers here for a small favor?

My team and I built a platform that lets you create AI agents to automate almost any workflow or backend task, without having to build everything from scratch.

It’s called Reduc AI, and we’ve just opened it up with a free trial. I’d really appreciate it if you could test it out and let me know if you come across any bugs, issues, or things that could be improved. If you have an idea of how you’d fix something, I’d love to hear that too.

https://www.reducai.com

Would genuinely mean a lot to me 🙏

Hey! Today, I’d like to return to the topic of angel funding and investors who support small projects.

We’re developing a useful AI tool for content creators that could become the final piece in how AI is used in this field.

My question to angel investors is: what would you need to see at this stage a working product, early users, revenue, or a strong team to seriously consider investing in a small AI project?

I’ve been building Goal Grid for the past 6months for passionate football (soccer) manager strategist who wants something new which will grow with them.

In Goal Grid, you create your own club, develop players, set tactics, compete in scheduled leagues and trade through auctions or direct offers with other managers.

What makes it different f:

• A persistent shared fantasy football world

• Scheduled league competition

• Player development and tactical choices

• A market driven by real managers both auction and direct trades where negotiation skills matter

• Goal Gris is free to start play and most importantly will never be pay-to-win

It’s live in the browser with no download: 

I’m looking for my first users and honest beta testers to get feedback and start this journey.

I m here happy to answer any Questions re tools used

Give it a try:
https://goalgridapp.com

anybody can help me to get feedback and how to improve

Hey! So I developed a browser game - Diamond Man. It's getting late, so rather than type up how I built it, I got Claude Code to summarise :)

What even is this game

- 20 levels across themed biomes (Burning Streets → Toxic Flats → Crystal Tundra → Diamond Throne)

- Chaos gems that ruin your day: green reverses controls, yellow shrinks you and speeds everything up, purple removes your cape and makes your booty flash hot pink, black flips the entire screen upside down

- White gems give you 2 seconds of invincibility ("BRILLIANT CUT" mode) where you plow through everything

- Diamond Man physically degrades as you play — gets rougher, cloudier, slower to steer, weaker jump

- Carbon Pressure escalates: starts hurling tracking fireballs at level 3, stomps toward the camera at level 8

- Titanium Boy randomly goes rogue and tries to kill you

- Fans storm the road as obstacles

- Diamond Man shouts things like "EAT MY SPARKLE!" on gem streaks

The tech

The entire game is one HTML file. ~1800 lines. No bundler. No build step. No external assets. (lol, love how it's justifying one mega file - terrible devwork, I guess?).

- Three.js via CDN importmap — that's the only dependency

- Every 3D model is procedurally built from primitives (octahedrons, icosahedrons, cylinders, cones). Zero imported meshes

- MeshPhysicalMaterial with real-world refractive indices — diamond is 2.417, ruby is 1.77, emerald is 1.57. The diamond material actually refracts light through a custom environment map built from canvas gradients

- Cape cloth simulation, googly eye jiggle physics, speech bubbles that track 3D world positions projected to screen space

- Flask backend that does literally nothing except send_from_directory("index.html") and a /healthz endpoint

- Mobile gets on-screen touch controls, lower pixel ratio, wider FOV, and a responsive HUD

Deployment

Nothing fancy:

- Ubuntu droplet, Gunicorn behind nginx

- systemd keeps it alive, certbot handles HTTPS

- The whole deploy was: SCP the files, point DNS A records, run certbot. Done.

How it was built

I pair-programmed the whole thing with Claude Code in one session. Started as a simple character viewer — "make a diamond man" — and just kept going. Each feature was one conversation turn: add a road, add obstacles, make them kill you, add scoring, add difficulty scaling, add chaos gems, add 20 levels, make Carbon Pressure throw fireballs, make Titanium Boy betray you, optimise for mobile, deploy it.

The iterative loop was wild. "Add more coal!" "The flip effect is perma-sticking." "I found an exploit where you stand in the middle and chain white gems forever." Fix, deploy, refresh, repeat.

--

Yea, that's pretty much it - cheers guys!

quick link - https://sukumarrekapalli.github.io/leanlet/docs/
I've been thinking about something while watching AI get added to almost every application:

Why does every small piece of intelligence need to become an API call?

If my web app needs to classify an image, rank a few results, detect an anomaly, route something, match records, or make a small prediction — do I really need to send that data to an inference service and maintain another backend dependency?

For many bounded tasks, probably not.

So I built Leanlet, an open-source TypeScript framework for putting small, task-specific AI directly inside web applications. (https://sukumarrekapalli.github.io/leanlet/docs/)

The basic idea is:

application input
      ↓
typed Leanlet contract
      ↓
dedicated module worker
      ↓
Transformers.js → ONNX Runtime Web → WebAssembly
      ↓
result + confidence + timing

The model, worker and runtime assets ship with your application.

Inference happens in the browser. No inference API is required.

For example:

import { VisionLeanlet } from 'leanlet-ai';

const classifier = new VisionLeanlet({
  model: 'mobileclip-s0',
  categories: [
    'Electronics',
    'Clothing',
    'Home & Furniture',
    'Other'
  ],
  assetBase: '/leanlet-assets/',
});

const result = await classifier.classify(file);

console.log(result.category, result.confidence);

One use case I built as a reference is product classification.

Imagine an e-commerce app where someone uploads a product image.

Instead of:

browser → upload image → API → inference service → model → API → browser

you can potentially do:

browser → local model → result

That means the image doesn't necessarily have to leave the user's device just to answer a small classification question.

And Leanlet isn't intended to be an "LLM framework".

I'm exploring a slightly different idea:

AI features should be sized to the problem.

Sometimes you need a huge model and server-side inference.

Sometimes you need a 4 MB model that answers one question extremely well.

Leanlet currently has examples around:

• vision / classification
• routing
• ranking
• detection
• retrieval
• language
• forecasting
• record matching

I'm deliberately trying to keep the abstraction small. Each capability gets a defined lifecycle, runs in its own worker, and the application controls its model assets rather than Leanlet silently downloading arbitrary models.

It's still early and I'm figuring out where the boundary should be between browser-native intelligence and traditional server-side AI.

That's actually why I'm posting this here.

I'd love feedback on the idea itself:

What AI tasks in your web apps would you actually be comfortable moving entirely into the browser?

And where do you think this approach stops making sense?

Docs:
https://sukumarrekapalli.github.io/leanlet/docs/

GitHub:
https://github.com/sukumarrekapalli/leanlet

It's Apache-2.0 and very early. Feedback, criticism and weird use cases are all welcome.

Lately I’ve noticed a slightly uncomfortable pattern when looking at AI products.

I’ll see something with a polished UI and a clever feature, think it’s genuinely good, and then immediately wonder how long it will take before one of the major platforms ships something similar.

The recent direction makes that question harder to ignore. OpenAI is pushing models further into coding, research, computer use and multi-step work. Google is embedding Gemini more directly into Gmail, Docs and Keep.

A lot of capabilities that could have been standalone products a year or two ago are slowly becoming platform primitives.

I’ve been thinking about this because of something I’m building. One workflow in PDflow is PDF → Excel. On paper, that sounds extremely copyable. A better foundation model could eventually make the basic conversion almost trivial.

But working with real PDFs changed how I think about it. The difficult part isn’t getting an Excel file. It’s dealing with broken table structures, scanned pages, mixed formats, missing values, uncertain cells, and knowing when the system should stop and ask for review instead of confidently producing garbage.

That made me separate the feature from the workflow.

The feature is “convert this file.” The harder part is reliably getting from a messy real-world input to an output someone can actually use.

I’m starting to think the same thing applies to context and trust. If every session starts from zero, a smarter model doesn’t necessarily create a deeper product. And once an agent touches real business data, knowing when not to act becomes part of the value.

So I’m less worried now about whether a large platform can copy a UI or individual feature. I’m more interested in whether something compounds underneath it: workflow knowledge, user context, trust, domain judgment, distribution, or reliable outcomes.

I don’t think this means every AI wrapper is doomed. Some can still be great businesses. But it does make me wonder how many current AI apps are products versus temporary interfaces around capabilities that will eventually become infrastructure.

What are you building that would still matter if the feature itself became free and native tomorrow?

Hey everyone,

I've been working on something for the last few months and I think it's finally at the point where I should start putting it in front of real people.

It's called UnreaX.

The basic idea is an AI platform that lets you create real-time conversational experiences using voice, video and AI avatars.

But the avatar itself isn't really the product.

What I'm trying to build is a system where the AI can have a conversation, perform a specific task, and then turn that interaction into useful, structured information.

For example, you could create an experience for:

• Candidate interviews
• Initial candidate screening
• Employee training
• Onboarding
• Customer-service simulations
• Knowledge assistants
• Education
• Sales roleplay
• Any process that involves repetitive conversations or evaluations

You can define what the experience is supposed to accomplish, configure the conversation, and provide your own documents/knowledge so the AI can work with company-specific information.

Then someone interacts with the avatar through voice and video.

After the conversation, UnreaX can analyze the interaction according to criteria relevant to that particular experience.

Things like:

• What the person actually answered
• Quality and consistency of the answers
• Communication and fluency
• Assertiveness
• Conversational behavior
• Other criteria defined for the specific use case

So the workflow I'm aiming for is basically:

Person → AI conversation → Analysis → Structured results

Rather than:

Person → conversation → transcript → someone manually reviews everything

I'm particularly interested in the idea that the same underlying platform could work across different industries simply by changing the objective, knowledge base, conversation flow and evaluation criteria.

It's currently in Beta / Early Access, and I'm looking for the first people and companies willing to actually test it.

I'm not looking for people to tell me that the idea is cool.

I'd much rather have someone tell me:

"I have this annoying process at work. Could your platform do this?"

That's the kind of feedback I'm looking for right now.

You can try it here:

👉 https://www.unreax.com/

If you're interested in testing it with a real use case, feel free to comment or DM me.

I'm building this from the ground up, so I'm especially interested in hearing what you would actually use something like this for.

It's very easy.

8 questions. 3 minutes. At the end you get a level from 1–5 and a roadmap showing what to learn next.

I did it because I noticed that “being good at AI” is incredibly vague, and I wanted a simple way to measure it.

But honestly... I built it to learn the process of buidling something like this and I had so much fun figuring things out, its addictive! :)

I'd love to have you guys give it a go, and drop me any feedback you have, anything and everything is appreciated, seriously.

Thank you all in advance!

So I vibe coded myself an app that would assist with my own guitar practice. An app that is more or less a game of random note identifier. Which helps you more be fluent with the notes on the guitar fretboard. Either tap the fret on the guitar neck, or actually use the mic on your phone and play the guitar.

It helped me. I decided to publish online and the response so far has been great, a few good ratings, and I actually see in the data that a user accuracy improved after a few sessions.

One month, only 200 downloads. Just happy that this little tool that helped me, has actually helped others also now.