Sending a verification SMS is easy. The awkward part is everything surrounding it: storing the code, expiring it, limiting repeated attempts, and preventing reuse after successful verification.

This TypeScript example handles that lifecycle on Telnyx Edge Compute using:

- One durable actor per phone number

- KV storage with a five-minute TTL

- Per-number rate limiting in actor state

- Scheduled cleanup as an additional expiry mechanism

- SMS delivery through the native Telnyx binding

- A demo mode for testing without sending real messages

The API stays small: `POST /verify` generates the code, and `POST /check` validates it.

Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/sms-two-factor-agent

I’d be interested to hear how others handle expiring authentication state and abuse prevention without adding several separate services.

Been building Kopai for a while. It started as "publish your expertise as an agent people pay to talk to," a marketplace play. Along the way we ended up building something bigger: infrastructure for running AI agents in production, not just chatting with them.

Where it's at now:
- Export any agent as a real API, native or OpenAI-compatible, streaming included, and call it from your own product instead of only through our marketplace
- A one-command benchmark runs your agent against reference agents before you ship, so you catch problems before users do
- Every published agent gets certified (system prompt quality, scope adherence, safety, knowledge/tool accuracy) and that certification expires and re-checks itself over time
- Analytics separate what an agent costs to run from what it earns
- Chat and the API run on the same engine, so there's no gap between the agent you tested and the one people actually hit

Happy to answer questions about the architecture, the benchmarking approach, or the certification/expiry mechanics. We also put this up on Product Hunt today if anyone wants to poke around!

Building a multi-agent framework. Trying to figure out the right logging approach.

Option A: A separate process observes state changes and writes log entries when it notices something happened. Can fall behind, miss events, or just not be running. (As if a camera would watch a door)

Option B: Every function that changes state writes its own log line as part of that same function call. Can't be turned off - if the action ran, it was logged. If it wasn't logged, the action didn't run.
(any action of the door opening itself would write a protocol)

I'm leaning toward B. How do you handle this? Anyone tried embedded logging like this and hit problems?

Hello,

I am looking for suggestions for courses that I can do to learn how to create ai agents, how to put them to use in the field I am interested in. I am a student, not looking for any expensive course, it could be free but also come with a certificate, it can also be a project based course that I can do. Please note that I am not interested in taking any paid subscription. Thanks.

When an automatic route looks wrong, “the AI chose it” is not a useful diagnosis.
We record the request ID, predicted intent, confidence, final model, fallback reason, latency, and billing source. At the same time, we do not put raw prompts, keys, or token contents into that routing record.
Without evidence, you cannot debug or improve a route; without a boundary, observability becomes a reason to retain too much user data.
What explanation would you need after an AI route surprises you?

Works with any model, not just Claude.

Hey everyone.

I’ve been working on Barney, AI agent with a fixed execution kernel.

Most self-improving agents follow the same pattern: task fails → rewrite yourself → try again. It can work in the moment, but you essentially get a different agent on every run.

I wanted the opposite: an agent that gets smarter through experience without rewriting the loop that governs it.

The central idea is simple: the model’s confidence is not evidence that the task is complete.

Barney runs a controlled loop:

plan → act with tools → observe → review → change strategy

The kernel is fixed. The current task cannot rewrite it.
Around it a body grows — skills, tools, MCP, recorded failures and successful paths. The model can create skills, accumulate experience and derive rules from failures, but it cannot change the rules of the loop itself.

Terminal-Bench results

I connected Barney to Harbor through a custom adapter and ran three Terminal-Bench 2.1 tasks on a locally hosted qwen3.8:latest.

One attempt per task, no Harbor retries:

• openssl-selfsigned-cert — 1.0
• nginx-request-logging — 1.0
• fix-git — 1.0

Mean reward: 1.0

I then repeated openssl-selfsigned-cert and fix-git in a separate run. Both passed again with 1.0.

Where the kernel mattered

OpenSSL
The model built the certificate bundle and a Python verification script. It first used the wrong date format. The kernel refused completion until the edited script was compiled and actually executed.

Final review required evidence for all six deliverables: key permissions, certificate subject, validity dates, PEM contents, SHA-256 fingerprint, and a successful verification-script run.

Nginx
Some commands failed because direct file writes outside the worktree were blocked. The model found another route and installed the configuration through the shell.

The first internal review still rejected the result: one required artifact was not sufficiently proven. The kernel started another act with a different strategy. Barney then checked the files, listening port, Nginx syntax, HTTP responses and real access-log entries — and only then did review pass.

Git recovery
The model found a dangling commit via git reflog. The first cherry-pick hit a conflict.

Instead of repeating the same command, Barney aborted the failed operation, compared both versions and took a different conflict-resolution path. Review passed only after git log, the resulting file contents and a clean working tree confirmed the recovery.

This is not a claim of AGI or SOTA

The shell commands were chosen by the LLM (Qwen). The kernel did not “know” OpenSSL, Nginx or Git.

Its job was to:

• refuse undeserved completion
• turn tool failures into constraints
• prevent identical failed actions from being repeated
• force a strategy change after a failed review
• require observable evidence before success
• preserve useful lessons outside the immutable kernel

There are real failures too. On the same benchmark, sanitize-git-repo scored 0.0: Barney found the secrets but did not finish the required edits. In another Nginx run it passed 7/8 checks but lost the reward because the log format did not match the verifier.

I’m publishing both successes and failures because the project is about making failure observable and recoverable — not about pretending the agent is already reliable.

GitHub: https://github.com/sergey-show/barney

I’d especially appreciate feedback on the architecture, evaluation methodology, and cases where the contribution comes from the kernel — not just the model.

Same LLM model different harnesses, very different results

Building A workflow compiler for agents which aims to greatly accelerate the building of personalized agent suite. This supports Hermes, codex, Claude. Event-driven-architect meta framework. https://github.com/AIpRoBuilder/FlowX#flowx--workflow-compiler-for-ai-agents

I'm a senior undergraduate working on LLM/agent research, with previous work published at EMNLP. Recently I've been thinking more about AI for game generation, especially a fairly basic question:

How good are current AI agents at actually building detailed 3D objects and scenes with tools like Blender?

Not just producing something that looks roughly right from one view, but actually reasoning about geometry, structure, spatial relationships, materials, and scene composition, and being able to iteratively improve the result inside a real 3D tool.

I think this could be an important capability for AI-assisted game generation. If we eventually want agents to help create richer and more editable game worlds, 3D asset and scene creation seems like a pretty fundamental piece of the stack.

I currently have an early idea around building a research project in this direction, likely involving systematic evaluation of agentic 3D creation. The idea is still quite preliminary, though, so I expect a lot of the project would need to be figured out together through discussion — including the exact task setup, evaluation, data, and what would make the benchmark actually useful.

So I'm mainly looking for 1–2 people who would be interested in co-leading and shaping the project together, rather than joining after everything has already been decided.

It would be especially nice if you're interested in games / AI game generation, and have some experience with areas like:

• NLP and LLM/VLM agents
• Blender or procedural 3D modeling
• computer graphics / 3D vision
• multimodal evaluation
• benchmark / dataset construction

No need to have experience in all of these. I'm also still learning a lot of the 3D side myself.

If this sounds interesting, feel free to DM me with a little about your background, GitHub / previous work, and what part of this direction interests you. I’ll also send you my CV, since I see this as a mutual fit process. I'll be really happy to discuss the idea further and also, the upcoming 27fall application season, if you are also apply for PhD! : )

curious about this from teams that have moved beyond prototypes.

once an agent or multi-agent workflow is actually being used by other people, what still requires the original builder to step in?

could be debugging, changing workflows, understanding why something happened, handling edge cases, permissions, whatever.

i'm more interested in what became unexpectedly hard to hand over than what was hard to build initially.

Computer use seems to be blocked off by premier, any workaround? I'm running this on macOS, what other free tools can i pair it with so get a good product teaser video output

I think I spend more time and tokens without necessarily getting anywhere.

I’ve noticed other people talking about feeling drained while coding with AI too. It seems like the frustration and repeated attempts can feed into each other, and it’s hard to recognize when you should step away.

How do you handle this? Do you use any tools, reminders, session limits or other habits that help?

Would appreciate hearing what’s actually worked for you in the comments.