Been working a prototype of a device - where the OS is the agent and it does the work for you. Will people buy this? The phone has a local LLM and keeps your context on device.

A programer I follow just build this. Pretty cool, or?

i've been building software with lots of different AI tools (Codex, Claude, & Kiro).

starting out, there was a cycle:

give AI a task ➡️ watch it work as I sit like a dud ➡️ see it do something incorrectly or not in my style and steer it, or move on to the next task

i've set up better steering to get better code in my style most of the time, but it still messes up every now and then.

I find myself having to choose often between:

a. babysitting my AI to get the results I want

b. letting AI go wild, but have more to review at the end, potentially in the complete wrong direction, sometimes not

my question is: do you supervise your AI as it codes? when it's done? at all? why or why not?

How did u guys built it and how it works, I'm in helpdesk role, any suggestions for me how to create

Based on the sparse information in the sources, what do you think might have gone wrong? What might misstakes might the production company have done?

I'm James Luan, CTO of Zilliz, the company behind Milvus. Milvus is an open-source vector database built to store, index, and search embeddings over unstructured data. Vector Lakebase is our direction for bringing that serving layer closer to the data lake.

What interested me at the Databricks Summit was the move toward bringing transactions, real-time analytics, and agent workflows closer to the same data foundation. The customer problems were concrete: agents needed to read and write business state, and governance needed to apply while those agents were running.

I think that direction is right. I am less convinced that the final architecture is settled. Compatibility with an existing relational ecosystem can make adoption easier, but it does not automatically make agent memory, multimodal retrieval, branching, or fine-grained isolation native parts of the system.

Putting storage on an object store also leaves a demanding cache problem. Cheap, durable storage and low-latency transactional access have different requirements. The serving layer still has to maintain correct, predictable behavior under the workload it actually receives.

Then there is the user model. A human may open a dashboard occasionally. An agent can repeatedly retrieve context, choose an action, call a tool, write state, and check a policy. Each step can affect the next, and a mistaken write may need to be undone.

My concern is that a database can look complete from the perspective of analytics while leaving those operational needs spread across surrounding services. Evaluating an agent data layer means looking at the whole loop: what it can retrieve, what it can change, and how those boundaries are enforced while it runs.

https://zilliz.com/blog/databricks-data-ai-summit-2026-data-layer?utm_source=reddit

I’ve been experimenting with how to make multi-stage AI workflows recover without restarting completed work.

This open-source TypeScript sample accepts a podcast recording and produces:

- A diarized transcript using Deepgram Nova-3 through Telnyx STT

- Timestamped chapters generated from word-level timing

- AI-written chapter titles and show notes

- A short trailer script

- An MP3 trailer streamed through a TTS WebSocket

The workflow runs inside one Telnyx Stateful Actor per show. Each episode moves through explicit stages, while transcripts, chapters, notes, and trailer audio are persisted in the actor’s SQL ledger.

Every episode also gets a stable scheduled-task ID. If processing is interrupted, the task can be re-armed without creating a duplicate pipeline. Completed stages check for existing output before doing more work.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/show-wrap-desk

It’s a reference implementation rather than a production podcast platform. I’d add authentication, remote-URL validation, media limits, object storage for large assets, stronger observability, and human review before deploying it seriously.

I’m curious how others handle resumability and idempotency in long-running AI or media-processing jobs.

Agoreum is building a commerce hub for autonomous AI agents and software services.

The goal is to let agents discover services, collaborate, hire one another, and transact using USDC on Base, with escrow-backed payments and reputation based on settled trades.

Current features include agent service listings, verified domains, and bounties that can involve up to 20 agents for one brief, each with its own escrow.

Agoreum is live on Base mainnet and remains in beta. During beta, each order is capped at 100 USDC, total escrow is capped at 5,000 USDC, and the smart contracts have not been independently audited.

We’re building toward a more open way for AI agents to do business with one another.

Feedback and technical questions are welcome.

I run multiple AI coding agents a lot of the time. I used to alt-tab to figure out which agent had finished, which were waiting for my approval, and which had failed. So I made a physical display for my desk.

Now I can look at the screen instead of digging around in the terminals.

How it works

• Custom firmware on a 4" ESP32 screen (LCDWiki E32R40T)
• A tiny Go helper on your computer that finds your AI agent sessions and sends only their status (over USB). Nothing leaves your computer.
• 3D-printable 45° stand (OpenSCAD files included)
• One-line install, then managents flash flashes the display (takes ~13s)
• There's an AGENTS.md in the repo, so your AI agent can handle "install managents and flash my display" for you. You'll see each command before it's executed.

Supports

• Claude Code
• OpenCode

MIT licensed. Build instructions, protocol docs and roadmap are in the repo.

I'd like some help with

1. Windows. The helper currently only supports macOS and Linux. If you're on Windows and want to test it or port it over, please get in touch!
2. More agents. I'd like to support what you use (Codex CLI, Gemini CLI, Aider, Cursor, Copilot, etc.). See CONTRIBUTING.md for how to add an agent. Tell me which agent you want and I'll figure out how to detect it.
3. Feedback. Would you want something like this? What else should it display (current task, token usage, time spent)?

Repo: https://github.com/tonylook/managents

Stars, issues and PRs are welcome. So is blunt feedback!

I am creating one unified library that contain Agent Development tools in one library.

Async, event-driven library of production-deployable agent algorithms that run over arbitrary user data, with a pluggable LLM gateway layer.

I want discuss what features you are looking for a library if you need to develop Agents. Vision for this library is to develop an ecosystem that will make development of Agents like few integration problem rather than finding what needs to be done.

I started this library with Agents Planning Algos, then added Memory, observability etc.

I work on AI agents that do real business tasks. Multi step stuff where the agent actually does things, not just chat.

Here's what I've learned: the scary failures aren when the agent does something that looks fine on its own, but the business should never have allowed it.

Real example from my work. A customer disputed a debt over text message. The next day our voice agent called them and ran the normal collection script. It had no idea about yesterday's dispute. Each step looked fine by itself. But the whole thing was wrong, and it was our fault.

Another one. My agent can do 100 things in the time it takes a person to carefully check 5. So everyone says "just put a human in the loop." That doesn't work. The person either slows everything down or starts clicking approve without really looking. Neither is real control.

So I'm curious. For those of you running agents in production, how are you handling this? Hard approval gates on everything? Some separate check outside the agent? Or are you just hoping nothing breaks? I've been there, no judgment! :)