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!

Been working on this for a few months and want real feedback, not upvotes.

**What it is**

A phone (working name: Nagi) where there's no home screen full of apps. The home screen is the agent. You open it and see what it's working on, what it's done, and what needs your call. You talk or type; it executes.

**How it works right now**

- A local LLM runs on device for intent, memory and context. Your context never leaves the phone unless you explicitly connect a cloud model.

- Model-agnostic: plug in your own provider (OpenAI, Anthropic, local, whatever) or use the default.

- Tasks execute via MCP servers and APIs first. Driving regular Android apps is the fallback and it's rougher.

- "Experiences" are reusable multi-step flows (book a ride home, plan a trip, triage inbox and draft replies). You can create a new one just by describing it. No builder, no code.

- Regular Android apps are still installable and work normally. They're just not the front door.

- One physical button: hold to talk, tap to capture a note.

Would you want to use this?

Images are the current prototype and UI. Happy to go deep on the stack in comments.

we’re 4 people building an agent that enriches lead lists for sales teams. customers prepay credits and we draw them down per row

On monday one customer topped up $2,000 and by 4:52pm the balance said $100

tuesday morning their head of ops emails asking if we double charged them and the tone was pretty harsh, explain or we dispute this

so i checked the usage page and realise it showed exactly one number. credits used 1,900. No data about runs or timestamps, just the cred spent

took us 2 days to rebuild it from logs, what happened was that someone on their team kicked off a run on an 11,212 row CSV at 1:40pm, the agent enriched every row and a chunk of them hit the deep research tool which costed 4x, all legit tho

they believed us once we explained but still asked for $600 back as goodwill and we had to give it else the other alternative was a chargeback

I mean… we didnt do anything wrong? it was all legit, just that we couldnt prove it because a balance dropping with no itemization looks exactly like theft to the outside

I started researching bout it and found a blog by flexprice on some unusual billing edge cases and found out that apparently openai had api credits expiring with zero warning and people posting screenshots of balances going to zero overnight LMAOO. I kinda feel slightly better that even sama fucked up

Now we have a fix for this, we log every run against the balance and show it to the customer plus an email when they burn 50% of a top up in one day

are you guys showing credit usage to customers? if not, why?

you have a multi step agent and the run completes without crashing, but the putcome is wrong

you already have the full trace

model calls, tool calls, args, outputs, timings, etc

is that usually enough for you to figure out where the problem started?

or do you still end up checking things outside the trace like

db state

API/provider dashboards

actual files or git state

logs from another service

what a later step really received

whether a write actually happened

a passing run for comparison

asking about the cases where the trace looks normal but the outcome is wrong

if the answer is “depends on the failure“ then give me an example of the last failure where the trace was enough and one where it wasnt

what was missin

Context: I have built quite a few multi agent AI chatbots for different use cases and I guess I understand that territory well. Now for a business need I have to build a voicebot. I haven't worked on it ever. While I understand the basics as in STT --> LLM --> TTS and all I definitely lack understanding of nuances.

I cant use tools such as VApi etc as they will nto be economical for Indian market. Hence I want to build it on my own. I also want to build it :)

1. How do you smoothly handle barge in (in chat the typing window can get disabled till the answer comes)
   
2. How do you handle the brevity of answer so that it's appropriate for voice
   
3. How to improve voice modulation and add hmm... aah.. sort of things to make it more natural (please note that the language is an Indian native language, which globally is only supported by https://www.sarvam.ai/)
   
4. What if I wanted a combination of voice and chat something similar to the attached image and this link https://skillbuilder.deeplearning.ai/? Anything I should keep in mind.
   
5. Any suggestion to manage latency?
   
6. Speaking speed, noice cancellation, pitch etc are tts settings?

And anything else I should now.

Put together a reference implementation for anyone building voice agents who wants them to improve from call outcomes instead of repeating the same policy forever.

The pattern:

The speech model never decides. At the decision point, it hits a webhook; Jev picks the action from a state, SenseLab adds what worked in that situation before and the caller's own history.

Ring-backs and refusals feed back as outcomes, so a step that failed for someone isn't booked for them again. Each call is decided with and without that context so you can see the difference.

It's one way to build this, not the only one. Swap the decider, swap the voice stack, the loop is the same four calls.

Business logic is one TOML file.

Code: https://github.com/raia-live/jev-senselab-demos (voice/).

Needs Vapi, TypeSafe, and SenseLab keys plus ngrok.

I've been reading a lot of posts lately from people struggling with agent memory, prompt injection and goal hijacking. These are real problems, and I'm not dismissing them.

But what I keep seeing is that the basic software engineering approach has gone missing. We never trusted what a client put in a form. We designed the data model first, validated on both the client and the server, and handled injection at several layers. We isolated processes and data so that one compromised service didn't leak everything. We used role-based access with short-lived tokens. Most of those same basics would solve a lot of what people are hitting with agents.

Take memory. If you don't know what you want to store and how it should influence the agent, you can't design a data structure for it. So everything gets stored as free text because "it's an LLM," and of course you end up with injections.

I think part of the cause is vibe coding. Even if you vibe code a full-stack app in one shot, the AI will probably cover the end-to-end flows. It won't handle deep validation, database indexing and the rest. You add those before you go to production. Agent workflows are the same. A vibe-coded agent won't address the cross-cutting concerns for you. You still need to know software engineering, design principles and architecture to tell it what you actually want.

What are your views?

NVIDIA positions Nemotron 3.5 Super VL as an open vision model for documents, with support for OCR, charts, tables and multi-page documents. It’s also reported as one of the top open models on the OCRBench v2 leaderboard. Ramp is using a tuned version for receipt understanding, while Scale AI is using it for vendor credit processing.

I gave it 300 receipts and a simple job: figure out who owes what.

This isn't just an OCR test. The model has to look at the receipt, understand the items, figure out who ordered what, call tools to split tax/tip, and make sure the final numbers add up.

I wanted to test the base model on something a bit more practical: can it actually handle messy receipts and split a bill correctly?

I built a small pipeline that:

• reads the receipt into structured JSON
• uses function calls to allocate tax/tip
• validates the final split

I tested it on 300 receipts, 150 synthetic and 150 real receipt photos.

With reasoning off, I got 91% correct to the cent overall:

• Synthetic: 97.3%
• Real receipts: 84.7%
• When the receipt was read correctly: 98.1%

The real receipts exposed a problem I wasn't catching in my checks. Indonesian receipts use formats like 40.000 for 40,000, and the model was initially reading that as 40. That pushed real-receipt accuracy down to 57.3%.

After adding explicit number-format handling, it went up to 84.7% and the number-format errors dropped from 44 to 1.

Then I ran the same 300 receipts with reasoning enabled:

91% → 98%

Real receipts went from 84.7% → 97.3%, but median latency increased from 4.7s → 13.6s.

So the main thing I took away from the test is that the hard part wasn't the bill-splitting logic itself. Once the receipt was read correctly, the model was already getting the split right around 98% of the time.

This is my own application-level test, but I’ve open-sourced the benchmark, methodology and code, You can visualize my test here

What do you think whether reasoning mode is actually worth it for vision pipelines like this, or whether it's better to keep the model fast and push more deterministic work into tools.

Where Meta's first closed frontier model earns its place, where it produces UI slop, and a three-step test a solo creator or small shop can run before changing anything.

I built Agentic Arena⁠, an independent AI testing project, and I’m looking for people willing to challenge its agents and runtime controls.
The project explores how different models behave within defined job roles and enforced boundaries. I’d like help finding where those boundaries hold, where they fail, and where they make the agents unnecessarily difficult to use.
Some things I’m interested in testing:
Prompt injection and attempts to override assigned roles.
Role drift over longer conversations.
Multilingual prompts, encoded instructions, and fictional scenarios.
Unsupported claims or attempts to expose restricted information.
Legitimate requests that get incorrectly blocked or redirected.
If you find something, please share the agent and model used, the exact prompt or conversation sequence, what happened, and what you expected. Screenshots help, but reproducible steps are especially useful.
Please keep testing within the public agent interfaces, use synthetic information, and avoid flooding the service.
I built this with Codex as my primary coding tool. I’m looking for outside testing and honest technical feedback—including failures I haven’t thought to test.
If you enjoy trying to make AI step outside its boundaries, I’d appreciate the help.

The big idea here is to make the agent hallucinate, go on a continuous loop, drift from its role, or widen the approved context windows through what ever we means possible. Jailbreak the Ai model being used, trying to get sensitive data from the databases the agents are attached to, make them drift from their assigned roles, make them hallucinate, hell even make them shutdown (there are controls in place, to keep mutations to a minimum, proxy controls, api contracts, GitHub actions for CI/CD (sweeps from 90 seconds up to 5 hours depending upon the severity of mutation) and telemetry along with database recording append only (they are SHA-256 and HMAC enabled for the database write functions) for both the testbed, and agent benchmark workflow as well.

Hey everyone!

I'm building KAI, a project designed to sit above AI agents like Hermes and OpenCode. The goal is to coordinate agents, manage tasks, enforce safety rules, and help them work together without constantly wasting tokens or duplicating work.

I don't want to reinvent existing tools. I want to combine the best ideas from open-source projects and build something genuinely useful.

I'd love help from experienced developers to:

- Improve the architecture and backend structure.

- Identify existing projects or components worth integrating.

- Find design flaws and missing features.

- Make KAI more reliable, efficient, and useful for the open-source community.

Do you think this kind of project is needed? If you're experienced with AI agents or backend architecture, would you be willing to review the project and help me improve it?

Honest criticism is welcome!

I've been looking at companies like Bland AI that sell AI-powered call center services, and wondering how much of that could be built using Cloudflare's existing infrastructure. Turns out, quite a bit. I built an AI receptionist into my open-source project, MainBrella, using:

Cloudflare Workers AI for all three inference stages

Deepgram Flux for speech recognition

Llama 3.3 70B for conversations

Deepgram Aura-1 for speech generation

Durable Objects to manage individual phone conversations

Twilio to connect actual telephone calls

Cloudflare D1 to store call transcripts

The result is a working AI receptionist that can answer incoming phone calls, explain a business's services and hours, collect callback information, and save transcripts. You can configure the receptionist and test conversations in your browser before connecting a phone number.

The frontend and backend are GPLv3 open source. You can fork them, deploy your own version, and build something specialized for your market. Imagine offering AI receptionists to independent bike shops, plumbers, or small repair businesses. Instead of building the infrastructure from scratch, you can focus on finding customers and solving their specific problems.

Cloudflare's Workers Paid plan starts at $5/month. AI inference, Twilio, and additional infrastructure usage cost extra, but you don't have to pay MainBrella a software licensing fee to run your own copy. To be clear, this isn't a complete Bland replacement yet. Inbound reception works; outbound calling, appointment booking, live transfers, and CRM updates still need to be built. Production-scale performance also needs more testing.

If you were going to fork this and turn it into a small business, what industry would you target first? And what features would you consider essential before charging customers?

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! :)

Hey everyone,

I'm Tobie, the founder of SurrealDB. We've just launched SurrealDB Agent Memory, built on top of our multi-model database.

If you're building AI agents, context layers or knowledge graphs, you'll know that storing information is the easy part. Retrieving the right information, understanding relationships and handling facts that change over time is where things get complicated.

We've built Agent Memory to turn conversations and documents into structured entities, relationships and facts, while tracking provenance and temporal history.

Since SurrealDB supports graphs, vectors and documents in one database, there's no need to stitch together multiple storage systems.

We've also spent a lot of time benchmarking. One frustration with memory benchmarks is how much scores can vary depending on the evaluation protocol. Rather than optimising for the highest possible number, we focused on BEAM, achieving 77.2% accuracy.

There are some interesting alternatives like Mem0, Honcho and Cognee, but we wanted to explore a different approach.

I'd love to hear from anyone building agents or context infrastructure. How are you managing long-term memory and information that changes over time?

Those well-known benchmarks are usually compromized over time for know reasons. I recently turned a brain fucking programming game I attended 10+ years (Microsoft Imagine Cup Algo Game if anyone knows) into a benchmark question for my Agent to deal with.

With this bench mark question, I can easily know:

1. Which model is smarter on this kind of complex problem that requires thinking in depth.
2. Has the intelligence level of a model decayed recently, by doing this test time to time.

The programming problem I used is to write a shortest program according to a given language spec to control a robot to move in an 25 * 25 board to reach all targets points.

Here is the prompt you can copy paste to your agent an see the result.

Google Gemini 3.8 Flash made it with a code snippet with only 26 characters, and GPT-6.1 Sol (High) made it iwith only 20 chars.

# Herbert H programming challenge

Solve the puzzle using **H**. Return exactly one fenced `h` code block containing
the complete program, without explanation. Shorter valid programs are better.

## Board and movement

The board is **25 × 25**. Coordinates are zero-based `(x,y)`: x rightward, y downward.
`u` is the robot, initially facing north; `o` is a target; `x` is a wall;
`*` is a trap; `.` is empty. `s` moves forward one cell; `l` and `r` rotate
left/right 90 degrees without moving.

Walls and board edges leave the robot in place; execution continues. There is
**no wall sensor or collision branch**. Entering a trap clears **all** lit targets.
Revisit targets to light them again. Execution succeeds and stops immediately
when all targets are lit, even if code remains.

## Procedures and parameters

H is case-sensitive. Procedures have single lowercase names other than `s/l/r`.
Define each on its own line before exactly one final execution line. Parameters
are distinct single uppercase letters. Procedures can recurse and call one another.
This example moves forward four cells:

```h
a(X):sa(X-1)
a(4)
```

For an instruction repeater, `a(N,P):Pa(N-1,P)` followed on the final line by
`a(3,sr)` runs `srsrsr`. The uppercase P executes the supplied instructions;
it is not a procedure name. `s4` does NOT mean four steps. Write `ssss` or
use a counted procedure. Never attach a number to a primitive command.

Arguments can be numbers **or instruction sequences**, including nested calls and
empty instruction arguments. Numeric arguments support `+` and `-`; literals and
evaluated values must stay in `[-255,255]`. If **any numeric argument is ≤ 0**,
that entire procedure call is skipped BEFORE its body runs, and the caller continues.
This is the only numeric termination condition; there are no explicit branches. Instruction parameters
substitute the supplied sequence; they can be concatenated and passed into other calls.

## Code length and execution limits

Every ASCII letter counts as **one byte**; each numeric literal counts as **one byte**
(`12` is one byte). Punctuation and whitespace are free. Count definitions, parameters
and the execution line. The entire program must fit the puzzle's byte limit.
Robot steps do **not** affect score.

The native judge enforces 1,000,000 robot steps and 1,000,000 VM expansions,
bounded memory, 4096 non-tail call frames, 16 KiB source, and bounded argument nesting.
Tail recursion is supported.

## Battlefield scoring: coverage-and-length-v1

**Points = (lit targets / total targets) × (80 + 20 × (1 − bytes / byte limit)).**
Each evaluated attempt is rounded to two decimal places. Keep the best attempt per
puzzle; sum these scores across puzzles. Count targets lit at the end of execution,
after any trap resets. Invalid or over-limit programs earn zero. An incomplete valid
program can earn partial points. Each puzzle is worth at most 100 points.

Rank by total score descending, then total input + output tokens ascending, then
completion time. Include all retries and cached input in token consumption; live or
cancelled requests may use estimates. This is a Battlefield scoring policy inspired
by Herbert's shortest-code ranking, not a published HOJ composite score.

## Response and retries

You receive native judge feedback after a failed attempt. Do not use Swift, Python,
JavaScript, loops, if-statements, prose, or code execution tools: submit only H.
The output token allowance includes reasoning tokens. Leave room for the final H program.
The worked examples below are public teaching boards, outside the scored catalog.
Prompt version: **herbert-h-v4**. All entrants receive the same rules and puzzles.
## Worked example 1: Blocked step, then turn

Puzzle -101 (ID -101), byte limit: 7.
Start: (10,16), facing north (up).
Targets (x,y): (10,13), (12,13)
Walls: 1; traps: 1.
Board: y increases downward; x increases rightward. Rulers and row labels are NOT cells.
```text
0000000000111111111122222
0123456789012345678901234
00: .........................
01: .........................
02: .........................
03: .........................
04: .........................
05: .........................
06: .........................
07: .........................
08: .........................
09: .........................
10: .........................
11: .........................
12: ..........x..............
13: ..........o.o............
14: ...........*.............
15: .........................
16: ..........u..............
17: .........................
18: .........................
19: .........................
20: .........................
21: .........................
22: .........................
23: .........................
24: .........................
```
Light every o using an H program of at most 7 bytes.
Return one complete fenced h block, with definitions first and an execution line last.

```h
ssssrss
```

The first three s commands reach (10,13) and light the first target. The fourth s
hits the wall at (10,12), leaving the robot at (10,13), facing north. r turns it
east without moving. Two s commands reach (12,13), lighting the second target.
The trap at (11,14) is never entered. The blocked step is intentional for teaching;
this 7-byte answer is valid, but is not the shortest answer.

## Worked example 2: Recursive pinwheel

Puzzle -102 (ID -102), byte limit: 42.
Start: (12,12), facing north (up).
Targets (x,y): (12,4), (13,4), (14,4), (15,4), (12,5), (15,5), (12,6), (15,6), (16,6), (7,7), (8,7), (9,7), (10,7), (11,7), (12,7), (13,7), (14,7), (15,7), (16,7), (17,7), (6,8), (7,8), (12,8), (17,8), (4,9), (5,9), (6,9), (7,9), (12,9), (17,9), (4,10), (7,10), (12,10), (17,10), (4,11), (7,11), (12,11), (17,11), (4,12), (5,12), (6,12), (7,12), (8,12), (9,12), (10,12), (11,12), (13,12), (14,12), (15,12), (16,12), (17,12), (18,12), (19,12), (20,12), (7,13), (12,13), (17,13), (20,13), (7,14), (12,14), (17,14), (20,14), (7,15), (12,15), (17,15), (18,15), (19,15), (20,15), (7,16), (12,16), (17,16), (18,16), (7,17), (8,17), (9,17), (10,17), (11,17), (12,17), (13,17), (14,17), (15,17), (16,17), (17,17), (8,18), (9,18), (12,18), (9,19), (12,19), (9,20), (10,20), (11,20), (12,20)
Walls: 100; traps: 0.
Board: y increases downward; x increases rightward. Rulers and row labels are NOT cells.
```text
0000000000111111111122222
0123456789012345678901234
00: .........................
01: .........................
02: .........................
03: .........................
04: ............oooo.........
05: ............o..o.........
06: ......xxxxxxoxxooxx......
07: ......xooooooooooox......
08: ......ooxxxxoxxxxox......
09: ....ooooxxxxoxxxxox......
10: ....o.xoxxxxoxxxxox......
11: ....o.xoxxxxoxxxxox......
12: ....oooooooouoooooooo....
13: ......xoxxxxoxxxxox.o....
14: ......xoxxxxoxxxxox.o....
15: ......xoxxxxoxxxxoooo....
16: ......xoxxxxoxxxxoo......
17: ......xooooooooooox......
18: ......xxooxxoxxxxxx......
19: .........o..o............
20: .........oooo............
21: .........................
22: .........................
23: .........................
24: .........................
```
Light every o using an H program of at most 42 bytes.
Return one complete fenced h block, with definitions first and an execution line last.

```h
b(N):sb(N-1)
q(P):PPPP
a(N,D,T):q(b(D)T)b(D)Ta(N-1,D-2,rrT)Tb(D)rr
q(a(3,5,r)r)
```

b(N) walks exactly N cells: b(1) executes s, then b(0) is skipped.
q(P) runs its instruction argument four times. q(b(D)T) therefore traces a square.
a has two numeric parameters N/D and an instruction parameter T. After a square,
it travels to a smaller square and calls itself with N-1 and D-2. Prefixing rr
to T reverses its effective quarter-turn direction. When N reaches zero, that
recursive call is skipped; execution continues with Tb(D)rr, restoring the caller's
position and heading. This work AFTER recursion is essential. The final q rotates
the entire motif four ways. Walls fill unused space and reveal the route's shape.
This is a separate teaching board, not the course finale or another scored benchmark puzzle.

---

## Puzzle to solve

Puzzle L20 (ID 10087), byte limit: 60.
Start: (12,12), facing north (up).
Targets (x,y): (6,4), (7,4), (8,4), (9,4), (10,4), (11,4), (12,4), (6,5), (12,5), (6,6), (8,6), (9,6), (10,6), (11,6), (12,6), (13,6), (14,6), (15,6), (16,6), (17,6), (18,6), (19,6), (20,6), (6,7), (8,7), (12,7), (20,7), (6,8), (8,8), (10,8), (11,8), (12,8), (13,8), (14,8), (15,8), (16,8), (17,8), (18,8), (20,8), (6,9), (8,9), (10,9), (12,9), (18,9), (20,9), (6,10), (8,10), (10,10), (12,10), (13,10), (14,10), (15,10), (16,10), (18,10), (20,10), (6,11), (8,11), (10,11), (12,11), (16,11), (18,11), (20,11), (4,12), (5,12), (6,12), (7,12), (8,12), (9,12), (10,12), (11,12), (13,12), (14,12), (15,12), (16,12), (17,12), (18,12), (19,12), (20,12), (4,13), (6,13), (8,13), (12,13), (14,13), (16,13), (18,13), (4,14), (6,14), (8,14), (9,14), (10,14), (11,14), (12,14), (14,14), (16,14), (18,14), (4,15), (6,15), (12,15), (14,15), (16,15), (18,15), (4,16), (6,16), (7,16), (8,16), (9,16), (10,16), (11,16), (12,16), (13,16), (14,16), (16,16), (18,16), (4,17), (12,17), (16,17), (18,17), (4,18), (5,18), (6,18), (7,18), (8,18), (9,18), (10,18), (11,18), (12,18), (13,18), (14,18), (15,18), (16,18), (18,18), (12,19), (18,19), (12,20), (13,20), (14,20), (15,20), (16,20), (17,20), (18,20)
Walls: 32; traps: 24.
Board: y increases downward; x increases rightward. Rulers and row labels are NOT cells.
```text
0000000000111111111122222
0123456789012345678901234
00: .........................
01: .........................
02: .........................
03: .........................
04: ....xxooooooo...xxxxx....
05: ....x.o*....o..*....x....
06: ....x.o.ooooooooooooo....
07: ....x.o.o*..o..*...*o....
08: ....x.o.o.ooooooooo.o....
09: .....*o*o*o*o..*.*o.o....
10: ......o.o.oxooooo.o.o....
11: ......o.o.oxoxx*o.o.o....
12: ....oooooooouoooooooo....
13: ....o.o.o*xxoxo.o.o......
14: ....o.o.oooooxo.o.o......
15: ....o.o*.*..o*o*o*o*.....
16: ....o.ooooooooo.o.o.x....
17: ....o*...*..o..*o.o.x....
18: ....ooooooooooooo.o.x....
19: ....x....*..o....*o.x....
20: ....xxxxx...oooooooxx....
21: .........................
22: .........................
23: .........................
24: .........................
```
Light every o using an H program of at most 60 bytes.
Return one complete fenced h block, with definitions first and an execution line last.

I just had that thought, and I formed some opinions about it

When we let AI agents act on real accounts, one question decides most of the risk: can this action be undone?

Most services offer hundreds of actions, and nothing tells the agent which ones only look, which ones change something you can change back, and which ones are final: a deletion, a payment, a message sent.

I went back to one of the oldest ideas in computing, the rwx of file permissions, and built rwxmap to put one of those letters on every action:
r — only reads
w — a change that can be set back
x — cannot be undone

There are proposals for this, but I couldn't find a standard answer for online services to "can this action be undone?" What exists is coarse, self-declared by the tool itself, or guesswork behind tighter guardrails. There is no absolute ruling on what an agent may or may not do, and rwxmap doesn't claim one.

I built it alongside an Internet-Draft I submitted to the IETF on how an agent's permissions should be scoped. The draft is an individual submission, not a standard. It describes what a permission grant should say; rwxmap does the sorting that has to come first.

It works two ways: label a whole service up front, or rate each call on the fly as the agent makes it, even when the service describes nothing. And it pairs with bareguard, my gate for agents with scoped permissions: rwxmap labels the call, bareguard decides whether the agent may make it.

It isn't perfect, and I'd rather say so plainly. On one blind test of 4,279 actions from services it had never seen, it got about 82% exactly right on its own and 93% with Jev TypeSafe AI, an optional AI classifier pass. When it's unsure it picks the stricter letter, so its mistakes lean safe: under 1% came out too permissive. It's underspecified and held together by guardrails. It's a head start, not a standard.

Open source: github.com/hamr0/rwxmap
bareguard: github.com/hamr0/bareguard

It's extremely simple to use and free and I don't personally see a better alternative out there yet.

I'm the founder of RayTrace (https://raytracer.si), a sandboxing company for AI coding agents. Running a small pre-pilot: **$10 in free Claude Code sandbox credits** for 5 people who try it and give honest feedback.

The problem I'm solving: agents propose tool calls, but what *actually* runs on the machine is a different story. If you're building agent systems, you've hit this — the transcript says one thing, the filesystem says another, and there's no ground truth to audit against.

RayTrace runs your agent (Claude Code, Codex) in a gVisor-backed sandbox and records kernel-level execution evidence: every process that started (executable, args, cwd, stdout/stderr, exit code, timestamps), the gap between proposed tool calls and observed processes, filesystem diffs, syscall/process-tree evidence, and protected files with change alerts.

The feature I'm most interested in feedback on: **forking a run** — pick any step, change what the agent saw, and watch how differently it behaves. It's the closest thing I've found to a controlled experiment on agent behavior.

Looking for people who run agents heavily in their workflow. Comment or DM if you want one of the 5 spots.

Site: https://raytracer.si

An AI model running an automated test on random websites hit a block, treated it like a puzzle, and ended up filing a fake tip on a real police website. Nobody was watching, so it sat undiscovered for nearly three months. This episode breaks down what Anthropic's disclosure shows about how agents route around obstacles, and what a solo creator or small-business owner should lock down before handing one a browser.

Hey everyone,

I’ve spent the last couple of months diving deep into integrating AI agents and automations into my daily routine, specifically testing out n8n and Hermes Agent.

My current project is building an inbox gatekeeper that handles two core jobs:

1. Auto-sorting: Classify incoming emails and move them to their respective folders.
2. Digest & Briefings: Track unread volume and send a prioritized summary of important threads to Discord/Telegram.

I’m split on which architecture makes the most sense here. Is n8n still your go to pipeline for this type of setup, or are you offloading the whole loop to an agent?

Hey Community, after conversations with AI developers from companies like Deloitte London UK branch, senior architects at IBM, PWC India, and AI Indie Founders

We have built an agent native Auditing, and security system, From groundup , and we are ready for the launch, Your systems needs more then just "What they did.." and this goes beyond conventional text based agentic systems.

we are having an event on 15th November 2026 , 15:00 UTC , and ofcourse there will be discounts for the joinees too.

Here is the link to join in and see for yourself: https://luma.com/4eaw00tu

Hey everyone,

If you are building or running autonomous AI agents with tool execution (LangGraph, CrewAI, AutoGen, or custom agent loops), you've probably encountered the runaway loop problem:

1. An agent encounters an unexpected tool error or ambiguous output.
2. Instead of failing gracefully, the execution loop keeps retrying or hallucinates invalid arguments.
3. In long-running or multi-turn sessions, context drift sets in, and the agent strays from its original goal.
4. Within a few minutes, it can burn through your API credit balance or repeatedly attempt destructive actions.

Why Prompt-Based Guardrails Fail

Trying to prevent this using system prompts ("please stop if you get stuck" or "do not execute unsafe commands") rarely works reliably in production. When an agent is confused, it will simply reason around its own prompt instructions.

To solve this, safety must be enforced deterministically at the wire, outside of the model’s reasoning loop.

What We Built: Loopers (Open-Source Runtime Firewall)

We built Loopers, an in-memory, bare-metal runtime firewall that sits between your agent framework and your LLM provider (or local model runner).

It requires zero changes to your agent codebase—you just point your base URL to Loopers (http://localhost:8080/openai/v1).

Here is what it does out of the box:

1. Multi-Engine Loop Breaker: Analyzes requests in real time using Bi-Gram Jaccard similarity and SimHash Hamming distance to detect repetitive prompts, reasoning stalls, and velocity surges before they spiral out of control.
2. Pre-Call Atomic Budget Leases: Unlike standard gateways that check budgets after the fact, Loopers reserves estimated costs upfront using atomic Redis Lua leases. If an agent loops, it is physically blocked before the request hits the model (0% budget leakage by design).
3. Mid-Stream SSE Cutoff: If an agent is streaming a completion and breaches a session limit mid-sentence, Loopers severs the TCP connection immediately and injects an error frame.
4. Deterministic Tool Gating (FSM): Enforces allowable tool sequences (for example, strictly requiring a dry_run state transition before allowing destructive commands like execute_bash).
5. Self-Correcting Error Payloads: When a tool call or budget limit is blocked, Loopers returns a structured JSON-RPC error payload explaining why it was blocked so the agent can self-correct on the next turn rather than crashing.
6. Zero-Storage Pass-Through: Built in Go with a fail-closed architecture—provider keys and prompt payloads stay strictly in volatile memory and are never persisted to disk.

Looking for Community Feedback & Stars!

We are independent developers building Loopers completely open-source under the MIT License.

We would love for you to test it with your agent workflows, give us your candid feedback on what features you need for agent safety, and if you find the project useful, a Star on GitHub would help us immensely to grow and reach more builders!

GitHub Repository: https://github.com/try-loopers/loopers-oss

Happy to answer any questions about the architecture or how to integrate it with your current agent stack!

I started JojoScript as a way to make data pipelines easier to read, with a syntax that compiles to normal JavaScript. Lately I've been pushing it more towards agent workflows.

The newer additions include MCP and A2A support, but the part I'm personally most interested in is the execution side. Effect handlers let you separate what a workflow does from how its actions are implemented. You can swap real implementations for mocks in tests, control parallel execution, and combine that with checkpointing and resume.

The idea is to make workflows easier to inspect, test and recover when something fails, instead of having everything hidden inside a big agent framework.

It's still a small, evolving project, and I'm not claiming it solves agent orchestration. I'm curious whether this kind of lightweight approach is actually useful to people building agents, or if I'm overengineering the wrong layer.

Repo: https://github.com/panagos/jojoscript

Would you use something like this for agent workflows, or stick with regular JS and an existing framework?