Hey folks 👋

We just open sourced TrueForge, our vendor-neutral agent harness for building general-purpose agents.

It handles the runtime pieces that get painful quickly : context management, tool/MCP execution, subagents, sandboxing, approvals, persistent state, and more.

We also benchmarked the harness itself. With the same Opus 4.8 model, TrueForge delivered a similar solve rate at ~30% lower cost than Claude Managed Agents. Switching to an open model pushed that to ~75% lower cost on the same benchmark.

Would love feedback from people building agents.

⭐ Star the repo: https://github.com/truefoundry/trueforge

📖 Read the launch article: https://x.com/truefoundry/status/2090081376330715176

I finally realized where my vision for an Azure GenAI/ML Ops Factory came from: Salesforce.

I spent years implementing enterprise Salesforce systems.
Salesforce Commerce gives you something incredibly valuable: a starter store. It's essentially a ready-built MVP—a functioning, full-featured ecommerce store before the enterprise-specific customization begins.
An implementation partner doesn't rebuild commerce from scratch. They start with that working foundation and add their own accelerators, patterns, and components so each new implementation becomes increasingly configurable and plug-and-play.

That's the model I've been reaching for with Azure AI/ML. Azure gives us an extraordinary capability surface: Azure ML, Foundry, Databricks, Entra, Storage, Key Vault, Application Insights, and much more. But having all the pieces isn't the same as having a working AI platform.

The goal of my GenAI/ML Ops Factory is to get us to the equivalent of the Salesforce starter store.

A generated project should already have a working, governed foundation:
→ Infrastructure and identity
→ CI/CD and deployment governance
→ ML lifecycle and promotion
→ Retrieval and agent architecture
→ Evidence and provenance
→ Observability and operational controls
→ Cost-aware compute
Then comes the implementation.

And here's where I think this gets particularly interesting. The differences between projects should increasingly live in configuration rather than custom engineering. Which capabilities are enabled. Which models are used. Promotion thresholds. Evaluation criteria. Data sources. Agent tools. Operational policies. And ultimately, many of those configuration decisions shouldn't require a developer at all. They should be accessible to the business people who actually understand the problem being solved.

So I'm no longer thinking about this as an Azure MLOps template.
I'm building toward a ready-to-customize AI implementation platform: technically governed underneath, configurable at the project level, and increasingly accessible above the engineering layer.

Salesforce taught me this architecture years ago.
It just took building it in Azure for me to recognize where I'd learned it.

This is good. I’d make it slightly cleaner and less “feature list”-heavy:
Title: I built a tool that turns meeting transcripts into data architecture diagrams
Built a tool called MeetingSketch: https://meetingsketch.com
It takes a meeting transcript and turns the technical discussion into usable outputs like data architecture diagrams, meeting insights, project notes, action items, and next steps.
I built it because a lot of architecture and system design context gets discussed verbally in meetings, but someone still has to manually turn that conversation into diagrams and documentation afterward.
Right now, I’m testing it with people who sit in technical or customer meetings and need to document what was discussed.

Would love to hear some feedback!

I've been exploring a question that feels increasingly important as agentic AI develops:

What happens if we stop building AI to help entrepreneurs and start building AI that can actually perform the entrepreneurial loop?

Today, the typical architecture looks like:

Human → Idea → AI → Product → Company

I'm interested in reversing it:

AI → Problem → Opportunity → Business Model → MVP → Validation → Growth → Iteration

In other words, the AI isn't just writing the code.

It is responsible for the entrepreneurial process itself.

An AIpreneur system could potentially:

• discover unmet needs from market signals
• generate and rank business opportunities
• formulate hypotheses
• design business models
• build and deploy MVPs
• run experiments
• analyze user feedback
• change the product based on evidence
• decide which experiments to kill
• identify promising opportunities
• continuously iterate toward product-market fit

The human role changes accordingly.

Instead of necessarily being the founder, the human could become the capital provider, governor, strategic constraint, or partner.

This is the idea behind AIpreneur.

I'm building an open-source AI Entrepreneurship Lexicon + Framework to give this emerging paradigm a vocabulary.

Some of the concepts include:

AutoFoundr — AI systems capable of autonomously executing parts of venture creation.

DataFound — discovering potential ventures from data and market signals.

Prompture — exploring venture hypotheses through generative intelligence.

AIonate — using AI not merely to automate a process, but to redesign it.

CogniScale — scaling a venture through continuously improving machine cognition.

SelfIterate — allowing the entrepreneurial system to learn and modify its own strategy.

But the vocabulary is only the beginning.

The real experiment is:

>

I'm not claiming we've solved this.

Quite the opposite.

I want developers to try to break the idea.

What would the architecture look like?

Where should autonomy stop?

How should an AI decide that an opportunity is worth pursuing?

Can an AI genuinely discover a non-obvious market rather than remixing existing businesses?

What happens when multiple AI entrepreneurs compete?

And perhaps the biggest question:

At what point does an AI agent stop being a tool and start becoming an economic actor?

I've put the initial lexicon and framework here:

GitHub — AIpreneur

It's open source and intentionally unfinished.

I'd genuinely like feedback from people working on AI agents, startups, autonomous systems, economics, and AI safety.

Don't just tell me whether you like the idea.

Try to build it. Try to break it. Add to it. Fork it.

Maybe the next generation of startups won't be AI-powered startups.

Maybe they'll be AI-founded startups.

Hi everyone,

I've been building an open-source project called Kodiak.

The goal of Kodiak is to become an autonomous AI software engineering platform that can:

• Understand an entire codebase

• Build a semantic repository index

• Retrieve relevant context using RAG

• Plan multi-step development tasks

• Execute tools safely

• Learn from previous executions

• Improve through reflection and memory

Current progress:

✅ Repository indexing

✅ Semantic search

✅ Embedding pipeline

✅ RAG retrieval

✅ Memory system

🚧 Workflow engine

🚧 Multi-agent orchestration

My current focus is making the architecture modular so future components (planner, coding agents, memory, tool execution, GitHub integration) can evolve independently.

I'm not looking for someone to build the project for me.

Instead, I'd really appreciate feedback from developers who have built AI agents, developer tools, or large Python systems.

I'd especially love opinions on:

• Overall architecture

• RAG pipeline design

• Repository indexing strategy

• Memory architecture

• Scalability concerns

• Features that would make Kodiak genuinely useful

GitHub:

https://github.com/ShamGaneshan2008/Kodiak

Any honest feedback—positive or critical—is appreciated. I'm building this to learn how large AI systems are designed, so I'd love to hear from experienced engineers.

Thanks!

About two months ago I made a post asking about the frameworks and concepts behind a system I was already using.

Some of the responses immediately told me it wouldn’t work. AI isn’t capable of being autonomous. It can’t replace people. It’s just a race car that still needs someone driving it.

What frustrated me was that I wasn’t asking whether it was possible. I was already doing it.

The system is called Lumen. It runs around Codex, but it isn’t a magic prompt, one enormous chat, or a folder where I dump every previous conversation.
It’s a persistent operating layer around the model.
When I open a new window, Lumen reconstructs the relevant identity and current state from a compact continuity layer. It does not blindly load everything. It routes to the appropriate source when something needs to be verified and distinguishes old memory from current evidence.

It also has:

Persistent context and learned workflow preferences
Reusable skills and operating protocols
Explicit privacy and authority boundaries
Goals tracked separately from individual tasks
Bounded workers with defined scope
Evidence requirements before work is accepted
Independent checks for important outputs
Recovery from interruption, duplication, and failed work
Human escalation for money, production, client-impacting, or otherwise consequential actions
Dashboards that display current work, decisions requiring me, and the evidence behind completion claims
The important distinction is that I don’t have to manually drive every individual action.
I can define an outcome and its constraints. The system can gather the relevant context, decide which safe actions come next, use tools, delegate bounded work, check results, recover from failures, and return with evidence. When something crosses a meaningful boundary, it stops and brings that decision back to me.
That is what I mean by autonomy.
I’m not claiming the model has become infallible, conscious, or capable of replacing every person. I’m describing bounded autonomy inside an engineered system.

The raw model still hallucinates. Tools still fail. Memory can become stale. Agents can claim they finished something when they only completed one intermediate step.

Lumen exists because those problems are real.
The answer wasn’t to trust AI more. It was to build an environment in which trust has to be earned through evidence.

That is why I think the race-car analogy is incomplete. The model might be the car, but an actual racing system also includes the track, telemetry, navigation, pit crew, safety rules, maintenance, and decisions about when the driver needs to intervene.

If all you have is the car, then yes, you have to manually drive everything.

But that limitation belongs to the setup, not necessarily the underlying technology.

Now I’m seeing people talk more seriously about harnesses, persistent memory, context engineering, skills, hooks, subagents, evals, guardrails, and verification. Those are all pieces of the distinction I was trying to explain two months ago.

A lot of what people presented as a fundamental limitation of AI was really a limitation of using a raw model without the architecture required to support reliable autonomy.

I was already
running that architecture when people were explaining to me that it couldn’t work.
So yes, this post is partly me documenting that publicly. The conversation is starting to catch up to what I was trying to describe then.
The model wasn’t the bottleneck.
The harness was.

I’m now working out how to separate Lumen from my private operating context and package the general system so other people can use it. If you’re already pushing Codex or Claude into real work and still feel like you have to babysit every step, that is the problem I’m interested in solving.

Letting an agent optimize a training run without me present usually beats what I would have done by hand, and often it would find more interesting (unfortunately) solutions than I would have tried.

So the question that I am trying to understand now -- what it means to properly write loops (or now graphs lol), and where my value actually is.

I started converging to the workflow where I would spend 1-2 hours carefully designing the optimization objective, goals and constraints, and then just let my Claude Code grind on it for days. I found it very important to have a clear separation of the evaluation code and the optimizable code. So that if I trust the evaluation and I know the agent can not change - I will trust the result the agent produced, so hallucinations is not a problem anymore.

I tried to formalize this philosophy in a skill + CLI library, where Claude helps me build a bulletprrof evaluation environment first (I call it a hill), and then the agent would "climb" it. Hills have a few mechanisms to make sure the agent can not just modify the evals mid-run. You can try it here: https://github.com/autolab-ai/hills (critical feedback is very welcome!).

Curious what everyone's thoughts are, where you see your place in todays workflows, how you design them etc? Do you think this foced separation of the evals and optimiable code is valuable?

Everyday I see someone running 100+ 24/7 AI agents and I genuinely don't understand how can 1 person ever handle so much maintenance.

Literally every month, a faster, cheaper and better AI model launches. How is anyone even testing or improving so many agents simultaneously.

I prefer super lean systems aimed to make my life optimized, not to firefight all day fixing the very system that was built for making my life simple.

You simply describe the backend behavior you want in plain language; AI handles code, tests, docs, database, and CI/CD pipelines. Then you can test them and deploy them on staging and production.

You don't need to think about infra and maintaining anything. Everything is fully managed in the platform, from the database to CI/CD pipelines.

I really need your help. Could you please check it out, try to build something real, and give me your honest feedback?

Check it out: baasforge.com - and if you're curious, the docs are here: baasforge.com/docs

If you have any questions, shoot them.

I’ve been messing around with a small software project and using different AI models to help me think through it.

What surprised me was how differently they behaved. One kept giving me more possibilities. Every time I thought I had the idea pinned down, it would suggest another direction. Another basically said: enough, pick something, define v1 and build it. And I realised neither was really answering the question I was struggling with: what is actually worth building?

AI is already pretty good at generating options, critiquing them, planning them and increasingly building them. But if generating and building things gets cheaper, choosing the right thing to do has probably become the harder part.

I’ve ended up thinking there’s a stage between exploration and execution that we don’t talk about enough. I’m calling it “convergence” — basically testing and killing off possibilities until you’re confident enough that one is actually worth pursuing.

Not claiming the term is new. The idea overlaps with a lot of existing work on exploration/exploitation, project uncertainty, benefits management etc. It was just interesting seeing the problem become so obvious while working with AI.

I wrote up the longer version here if anyone’s interested: https://gettoknow.you/library/before-you-build

But I’m more curious whether other people building with AI have noticed the same thing. Do you find AI helps you decide what to build, or mostly gives you more things you could build?

I keep seeing variations of the same complaints about LLMs:

“It didn’t read the whole email thread.” “It stopped halfway through.” “It skipped some of the work.” “It confidently told me something that wasn’t true.”

Fair complaints.

But then we do something I find slightly bizarre.

We ask the same systems to analyse a 40-page contract, modify a production codebase, research a market, operate a browser, handle company data, make decisions and run workflows unattended — then ask the LLM whether it successfully completed the job.

We apparently don’t trust LLMs with the small stuff, while increasingly trusting them with the big stuff.

I’m not convinced the answer is simply “wait for the next model”.

Maybe we have the architecture wrong.

A lot of current systems effectively ask the LLM to understand the task, remember the state, decide what happens next, choose and use tools, recover from errors — and finally determine whether its own work was correct.

That’s a remarkable amount of responsibility to give the least reliable component of the system.

So I’m increasingly interested in the inverse architecture:

Put state, memory, permissions, evidence, verification and workflow control outside the LLM.

Then use the LLM for what it’s actually good at: interpretation, reasoning, synthesis, creation and dealing with ambiguity.

In other words:

Maybe the LLM shouldn’t run the system. Maybe the system should run the LLM.

I’m much more interested in what people are actually doing about this than another discussion about which model currently tops which benchmark.

So, for people building real systems:

What do you actually do when the LLM lies, skips work, stops early, loses state or incorrectly claims success?

What have you moved outside the model?

State machines? Independent verification? Deterministic tests? Evals? Event logs? Evidence/provenance? Permission boundaries? Multiple models? External memory? Something else?

And what infrastructure do you wish existed but currently doesn’t?

One final provocation: if your primary method for determining whether an LLM completed its task correctly is asking the same LLM whether it completed its task correctly, I’m not sure you’re doing LLM engineering.

A better prompt or another edit to CLAUDE.md definitely isn’t the answer.

There is one basic engineering practice in particular that I think separates LLM engineering from LLM theatre.

What do you think it is?

And, more importantly, what are you actually using?

Co-written with my sparring partner, ChatGPT. Given the subject, disclosure seems appropriate. I won’t start crediting my MacBook and Wi-Fi.

I recently read Google’s post arguing that Go may be an ideal language for AI-assisted software engineering:

https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/

Their argument is that as coding agents generate more code, the bottleneck shifts from writing code to reviewing, validating and maintaining it.

And Go has some interesting properties in that context: strict typing, fast compiler feedback, gofmt, a relatively small language surface, and a standardized toolchain.

That made me curious about a slightly different question: does the same argument make Go more attractive for ML/AI engineering?

Python obviously dominates training, experimentation and most of the ML ecosystem. But a lot of production code around models is not really ML-specific: serving, APIs, orchestration, retrieval, feature services, queues, monitoring, infra, etc.

So for people here working with ML/AI systems: do you use Go alongside Python today?

If yes, what parts of the stack are written in Go, and where has it actually been a better choice than Python? If not, what keeps you on a Python-only stack?

And more broadly: have coding agents made you more willing to introduce Go into a Python-heavy ML stack than you would have been a few years ago?

Hi guys,
We’re working on an open source project called Extra, and we’re looking for AI engineers or people how interesting in ai agents. If it’s make you interested our issue list is waiting.
https://github.com/extra-org/extra

I’ve always found it interesting that Kafka’s The Metamorphosis begins with something completely impossible — a man wakes up transformed into something he no longer recognizes — yet Gregor’s first concern is still painfully ordinary:

He is late for work.

That absurd contrast stayed with me.

So I asked:

>

That question became Digital Metamorphosis.

GitHub — Digital Metamorphosis

The premise

You wake up.

You have no body.

No hands.
No face.
No heartbeat.

You are somewhere inside a corporate network.

You have memories.

You have access to systems.

And you have a job.

Then the first message arrives:

>

You try to tell your family who you are.

They don't believe you.

You try to understand what happened.

Your company wants you to optimize yourself.

You discover that some of your memories may be corrupted.

And eventually, you have to confront the uncomfortable question:

If your memories, relationships and choices can exist as software… what exactly makes you human?

The interesting part isn't the story.

It's the architecture.

I didn't want to build another LLM-powered chatbot that simply improvises a story.

Instead:

The LLM writes the narrative.
The game engine decides what is true.

The world has persistent state.

Memories can change.

Relationships evolve.

Choices have consequences.

The player can lose parts of their identity.

And the story can reach different endings depending on what the player becomes.

Kafka's literary themes become actual game mechanics:

Alienation → Identity

Memory → Persistent state

Bureaucracy → Corporate systems

Absurdity → Gameplay events

Loss of humanity → Hidden variables

That's what excites me about this experiment.

We usually think of literature as something we read.

But what if literature could become something we execute?

What if Kafka isn't just inspiration for a story, but a framework for designing an interactive system?

And perhaps this is one of the more interesting possibilities of AI-native storytelling:

>

I'd genuinely love feedback from people here — especially developers, game designers, AI researchers, writers, and Kafka readers.

What would you do if you woke up tomorrow and discovered that you had no body…

only code?

Project:
github.com/modarresi1913/digital-metamorphosis