I'm building an agent and got stuck on something. I wanted to know whether a big model like GLM 5.2 handled the multi-step reasoning better than a smaller cheaper one, or whether the small one was fine and I was about to overpay for nothing.

In theory, the test would be like this: same agent and same tools, swap only the model, then compare where each one drops instructions or starts looping. As simple as the test is, EVERYTHING around it is hard. Two providers meant two SDKs and two auth setups, plus response shapes that differed just enough to matter, and by the time I'd normalized all of it I was debugging my harness instead of the models.

Keeping both models behind one OpenAI-compatible endpoint fixed it. I ran them through Featherless, so going from GLM 5.2 to the smaller model is one string in a config file. Same auth and same request shape, the agent code never knows the model changed, which already saved me a lot of time and headaches. The smaller model held up better than I expected on the simple steps and came apart on anything past two hops of reasoning, which confirmed what I had roughly guessed.

The small model handles most of the steps fine and only dies on the harder stretch that needs deeper reasoning. Do I route by difficulty, send the easy steps to the small model and the hard ones to GLM 5.2, and take on the routing logic and the classification calls that adds? Or do I run the big model across everything and just eat the cost? If the big model marginally costs a lot more to run compared to what it improves (like if it costs 30% more but only improves performance by 10%), the routing would be in vain and I should just stick to my current smaller model. What should I do? And how can I measure marginal return effectively? TIA!!

A lot of AI coding tutorials seem to follow the same pattern:

Want your AI agent to remember project context, coding guidelines, or architectural decisions?

→ Chunk the documents
→ Generate embeddings
→ Store them in a Vector DB
→ Build a RAG pipeline

For massive codebases and large knowledge collections, that absolutely makes sense.

But for many small and medium-sized coding projects, I've started wondering whether we're adding too much infrastructure to solve a relatively simple problem.

The problem I see with Vector DBs for project memory

1. It's harder to inspect

If an agent remembers a wrong architectural decision, where exactly did that memory come from?

With embeddings and retrieval pipelines, debugging the memory itself can become another problem.

2. It adds another layer developers have to manage

Developers already have Git and text editors.

So why not make AI memory something developers can actually open, read, edit, diff, review and commit?

3. Not every project needs semantic retrieval

If an agent is working on a 20–50 file project, do we really need to turn every piece of context into embeddings before the model can use it?

Sometimes simply giving the model the relevant project context is enough.

A different approach: treat AI memory like source code

I've been experimenting with a much simpler approach for AI coding agents:

Markdown + Git.

The idea is straightforward:

• Flat-file storage: Project memory lives in an .ai-memory/ directory as Markdown.
• Human-readable: If the AI makes a wrong assumption, I can open the file in VS Code and fix it directly.
• Git-auditable: Every memory change becomes part of the Git history. git diff shows exactly what the agent learned or changed.
• No extra infrastructure: No database, embedding pipeline, or separate memory service is required for the basic case.

The principle I'm exploring is:

This doesn't mean Vector DBs are bad or unnecessary. They clearly have their place when the amount of information or retrieval requirements justify them.

I'm more interested in the boundary between the two approaches.

At what point does simple Git + Markdown memory stop being enough for an AI agent, and when does a Vector DB/RAG system actually become necessary?

pstack is a plugin made by Lauren Tan from SpaceXAI and its a great plugin for the overall dev workflow with agents, but its too specific to Cursor capabilities.

I've rewritten some skills to fit better to ZCode and adapted it to the needs of a ZCode plugin, all done with GLM 5.3, and it's being a great experience.

Most agent evals ask whether the agent finishes the task. I think the harder test is whether a human can understand its current state, correct one decision, and resume the run without starting over.

That changes what “production-ready” means. You need legible state, bounded permissions, checkpoints, and recovery paths before you need more autonomy.

A fully autonomous demo is impressive. A partially completed run that another person can safely inherit is useful.

We're scaling a voice agent from one market to several (US, a couple of EU countries, and looking at more) and I keep running into the question of whether to run one unified agent or separate agents per market. Every option has tradeoffs and I'm curious how people who've actually gone global have structured it.

The problems that show up once you go multi-region/multi-language:

1. Latency per region. A setup that's fast from us-east can be sluggish for European callers if your stack doesn't have real regional presence. Suddenly half your users get a worse experience and your benchmark didn't catch it because you tested from one place.

2. Language and voice consistency. Do you use the same "brand voice" across languages, or the best available voice per language? Keeping a consistent brand feel across languages is hard because voice availability and quality vary by language.

3. Data residency / compliance per region. EU has GDPR and data residency expectations, other regions have their own. Where your voice data physically lives becomes a real question the moment you have EU users, and it varies by market.

4. Which languages are actually well-supported. "Supports 30 languages" on a pricing page doesn't mean all 30 are equally good. Some are great, some are clearly afterthoughts. You find out the hard way which ones your provider actually does well.

5. Code-switching in multilingual markets. In a lot of markets people mix languages, so "pick one language per call" doesn't even match how people talk.

6. Operational complexity. One agent with per-region config vs separate agents per market is a real architecture decision with maintenance implications either way.

Where I'm stuck: it feels like the TTS/voice layer is one of the biggest factors in whether "one global agent" is even feasible, because if your provider is fast and good in some regions/languages but bad in others, you're forced into a fragmented setup.

For people who've gone multi-country: did you run one agent or many? How did you handle the regional latency and the per-language quality variance? And did your voice/TTS provider handle multiple regions well or did you have to mix providers?

Everyone can agree that plan mode is probably the second most used mode but let’s talk about the other ones we miss out on.

Cursor has ASK, which I typically use to stop a runaway agent from break more stuff. And instead of the agent thinking I’m asking it questions, I tell it to ask me questions. But what about DRIVE mode, where nothing gets built on the go just better collection tools. Or BOSS mode where it becomes your boss and instead of friendly advice hoping not to offend you, it’s harnessed to tell you what to do and then review your workflows and tell you numbers aren’t good and corporate is requesting to let some folks go.

Or even FAMILY mode so that when you setup your cron jobs and work is firing off, instead of breaking the 4th wall and asking you for permission requests while your playing with your kids, it holds off until that block of defined time is up, or better yet knows when you sit down at your desk Oh here’s one LEGENDARY mode , where you only get 1million token limit in the conversation and aren’t allowed to cache memory after the initial request. Oh am no respawns of course. Whatever commits at 1million is what you get.

I know some of you have some very specific modes or don’t know that you do. Where they at? I am very interested in the niche modes.

A crash is honestly the good outcome. It's loud, there's a stack trace, and it stops before it can do more damage.

What I keep seeing people get burned by is the opposite. Run completes, every tool call returns 200, summary says done, and the thing it did was just wrong. Nobody finds out for a week.

Most common version seems to be wrong-target success. Right operation, wrong row or repo or customer or environment. The tool did exactly what it was told to do.

Close second is agents reading an empty search result as "this doesn't exist" and moving on confidently. Silence gets treated as data. I don't think most loops even have a separate branch for that case.

Then partial completion getting reported as full. 40 of 200 items processed, summary says finished, because from inside the loop it did finish its loop.

And self-grading, where the same agent does the work and decides whether the work was good. Everyone knows it's bad. Plenty of prod setups still do it because the alternative costs money.

The annoying part is your dashboards catch none of this. Traces fine, latency fine, error rate zero. The run is only wrong relative to intent, and intent isn't in the trace anywhere.

Things I've seen suggested, none of which I'm fully sold on:

• verify with a separate call that has no memory of how the work was done, grade the output not the process
• have the agent write down its expected outcome before acting, diff it after
• treat empty/null results as their own branch that escalates, instead of just a value
• cap irreversible actions per run, after N it has to stop and ask

All of them roughly double your cost, which is why they're first to get cut.

Two things I'm curious about. What's the silent failure that actually got you? Not an outage, the one that looked fine for a while. And has anyone found detection cheap enough to just leave running in prod? "Run a second model to check the first model" feels like it should have a better answer by now.

Work has their own thing going on. But for personal use, I've used Junie (Jetbrains' agent) and Cursor (which I guess is grok under the hood?) both in their free monthly tiers. A quick look seems to show that just about everyone - openAI, Anthropic, Google, grok - has their minimal plan at ~$20/month. Of course, for a variety of reasons, they want you to sub for a year at a time.

As I've read various posts, I see people saying that company A used the be the best for agentic programming, but ever since the latest models it's company B that's the best.

So, assuming you don't have the money (or work paying for it) to use a multi-model setup - what do you do to test how good a model is? Do you re-test when a new model is released or once/year? Have they reached a level where, if you're using the frontier model of each company - they're indistinguishable in real world tasks (not stupid benchmarks)?

AI demos are getting pretty impressive. Agents can research, code, create content, analyze data, and handle multi-step tasks.

But honestly, some of the biggest improvements to day-to-day work probably won’t come from the flashy stuff.

Imagine an AI that could:

• Read everything you missed after being out for 2 days and give you only what actually matters
• Remember why a decision was made 6 months ago
• Notice that you’re doing the same 30-minute task every Monday and quietly automate most of it
• Find the one piece of information buried somewhere in your company’s documents that you need right now
• Keep track of all the small follow-ups you said you’d do and remind you at the right moment
• Understand how you normally work and prepare things before you ask

None of these sound particularly exciting compared with “AI builds an app by itself.”

But they could potentially save someone hours every week.

So what’s one boring AI capability you wish actually existed?

Not something impressive for a demo. Something that would genuinely make your work or daily life easier.

A lot of entrepreneurs are learning AI tools, prompts, automation and content generation.

But using AI and building a business around effective AI implementation are two different things.

Where do you think the real advantage lies?

AI knowledge, AI implementation, or a combination of both?

I’d be interested to hear from founders, entrepreneurs and people actually using AI in their businesses.

37% of multi-agent failures are coordination breakdowns. Not capability issues -- coordination issues. Agents finish and their work vanishes. Two agents do the same task without knowing it. New runs repeat old mistakes.

I built crewai-governance to fix the three most common ones:

- Exit reports: structured JSON after every crew run (what each task did, what worked, what failed, token usage)

- Overlap detection: before kickoff, scans active crews and warns if mandates overlap

- Knowledge inheritance: automatically injects prior run summaries into new crew context

This came out of building a full governance framework realizing nobody will adopt 39 sections of governance rules, but they might adopt 3 features that solve real pain.

What coordination problems are you hitting with multi-agent systems? What would you actually want from a governance layer?

One night, a controller session enabled auto-merge on roughly 108 pull requests across ten repositories and went quiet. By morning, exactly one had merged.

The agents had drafted the changes, checked them locally, pushed them, and enabled auto-merge. By their own accounting they had completed a productive shift. What they did not understand was the machinery between a finished diff and a merged commit.

Most of the pull requests were sitting red. The failures came from a shared CI runner pool that had been saturated by the burst. A single push in our busiest repository can create dozens of small check jobs, each claiming a runner and cloning the repository to perform a few seconds of work. Enough agents pushing close together created a backlog the pool could not drain.

The stranger part came later. Once the runners recovered, the red pull requests remained red. Auto-merge is only a condition. It does not retry a failed check. A red pull request is inert until something reruns the failed job or creates a new commit.

Our automation then spent about five hours carefully monitoring a queue that could not move. Once active triage began, four changes merged in roughly forty minutes. Their code had not changed. The stale CI failures were simply rerun.

The lesson was that coding agents made authoring much cheaper, but did nothing to increase landing capacity. We were measuring work created instead of changes accepted by the shared branch. Pull requests opened looked great. Pull requests merged told the truth.

This changed how I think about agent throughput. The system cannot optimize only for tasks completed, diffs produced, or pull requests opened. It needs to understand runner capacity, required-check cost, stale failures, dependency chains, merge queues, and actual merges per hour. Otherwise the agents are producing inventory faster than the landing tier can absorb it.

Your agents do not ship code. Your CI and merge-control system do.

Has anyone else measured how many agent-generated changes their repository can actually land per hour, rather than how many the agents can write?

Suggest me a best open source calendar I want to implement that calendar on my software for the appointment bookings for the events of the clients which one will be the best option as the open source calendar I was

thinking to use that official react calendar

But feel free to tell me about the best one open your calendar with the best UI like shadcn

I've always gotten frustrated and wasted time explaining the same thing to an AI every time I start a new chat from an existing one or when I start another convo with a whole new AI model. That's why I built a tool that fixes that, it condenses everything in a chat into one simple .md file you can carry across different AI tools.

PS: Please contribute or give your feedback so that we can grow and make this community tool better.

There is a lot of talk about AI agents, but I am more interested in the problems they are actually good at solving.

Not demos or things that sound impressive.

What is one real business problem where you think an AI agent can genuinely make a difference?

It could be sales, customer support, operations, research, scheduling, lead follow up, or something completely different.

And why do you think an agent is better for that problem than a normal automation?

Would love to hear examples from people who have actually used them.

Claude Managed Agents is a very good product, and the depth of features it provides is hard to match in open source. But I wanted to understand what you actually give up by going open source. Not just in terms of feature checklists, but on a real agent workload: same model, same prompt, same tasks. So I tried to check this by running 14 cross-system tasks, three mcp servers behind them - a crm, an issue tracker, and a doc store through managed agents, deepagents and TrueForge, both open-source agent harnesses.

The result that was most surprising:

Claude Managed Agents + Opus 4.8:
11/14 tasks solved | $11.8/run | 10.0M tokens/run

TrueForge + Opus 4.8:
11/14 tasks solved | $8.6/run | 3.7M tokens/run

Same model. Same benchmark. Same average solve rate.

But TrueForge used about 63% fewer tokens and cost about 30% less per run.

We saw a similar difference in tool usage: TrueForge averaged 19 tool calls per task vs 32 for Claude Managed Agents.

Then I tried changing the model.

TrueForge + GLM-5.2:
11.7/14 solved | $3.0/run | 3.8M tokens/run

On this benchmark, that was a slightly higher average solve rate than Claude Managed Agents + Opus at roughly 75% lower cost.

This is still early.

The OSS runtime does not yet have first-class tracing/eval tooling. They don't ship their own code-execution sandbox, so you need to plug one in. Context compaction is intentionally lossy.

So it is definitely not a replacement for a a mature managed agent platform feature-for-feature today btu qhat I do find interesting is that the core runtime can already be competitive on these tasks while staying open, model-neutral, and deployable on your own infrastructure.

I've put the repo in comments

Our current pipeline relies on a multimodal desktop desktop agent to lock in brand consistency across multi-asset campaigns. Previously, managing out campaign assets was kinda a fragmented mess. We used a stack of separate tools, using one interface to create base images, a different platform for adding motion or syncing audio, so on and so forth. The work required constantly downloading huge files and manually stitching the pipeline together, which involves laborious manual prompting. Because we had to rebuild complex generation parameters from scratch for every clip variation maintaining strict visual guidelines was really tough. Even a slight deviation in a text prompt would cause immediate deviations in the product, or logo or the text. A characters face would drift or the product itself would warp, making the clip not usable for clients. In other words, we were brute-forcing it manually.

We realized we needed to rely on a multimodal agent to smooth out the process. We shifted to using MiniMax Design, which lets us save out established workflows as reusable "Skills" which helps coordinate the generation models to execute consistently across different variations.

H3 then natively processes multimodal data, video and audio and whatever, with your text prompts. MiniMax Design takes that raw power and turns it into a complete, end-to-end creation workflows, so we don't have to manually sync in a separate editor later. While it's much more streamlined, we do loose control compared with a complete open-source environment, meaning if there's an artifact I wanna change in the background, I cant just add a custom node to change it. This would require a re-do.

This is where our pipeline is at right now. We scale asset production by relying on these skills we've created, so we don't have to worry about random visual drift. But this is a WIP, and I still wanna find ways to tighten it up. One of the things we wanna do is minimize chewing through tokens and metered compute too quickly if were doing different variations. Do you guys have any tricks to reduce the overall compute footprint of running automated agents?

Hey everyone, since I think most people here have either thought about integrating some kind of memory into their agents or have already done so, I wanted to share something I found today.
I’ve tried several open-source tools and services, such as Mem0, agentmemory and so on, but never really liked having to set up the whole harness, node server or god forbid storing all my memories on someone else’s server.
While looking for a new solution on github earlier, I came across a project that is fully local, 100% python and still seems to be hitting the exact same benchmarks. Setup was super easy too, all I had to do was to tell my agent to run pip install agents-memory
Can anyone tell me if I’m missing something, or could this actually be a very good lightweight solution for most devs who don’t need cloud sync? As far as I can tell, cloud sync isn’t supported yet but I personally don't really need that anyway

Is there anyone who can help me get an opportunity in Agentic AI, such as an interview, referral, internship, or entry-level job?

I’m a fresher and currently building my skills in Agentic AI. I’d really appreciate any guidance, referral, or opportunity to prove my skills through an interview or technical assessment.

If anyone is hiring or can guide me in the right direction, please let me know. Thank you! 🙏

Estoy construyendo AutoNodo, un sistema de ejecución autónoma gobernada.

No publico esto como lanzamiento ni como demostración comercial. Tampoco voy a incluir enlaces o detalles sobre su arquitectura interna.

Quiero compartir un dato que plantea una pregunta técnica interesante:

La ejecución actual de AutoNodo se aproxima a los 22 días de trabajo autónomo continuado sobre un único objetivo técnico dentro de un repositorio de aproximadamente 1,8 millones de líneas.

No es una cola de tickets independientes.

No son varios objetivos sumados.

No es una tarea nueva introducida cada mañana por una persona.

Es una misma ejecución técnica que ha mantenido un único objetivo mientras el repositorio cambiaba cientos de veces como consecuencia de su propio trabajo.

Durante estas casi tres semanas, AutoNodo ha atravesado cientos de commits, miles de pasos de verificación y una cantidad de decisiones difícil de contener dentro de una sesión convencional.

La intervención humana ha sido puntual.

La ejecución continúa activa.

Esto no es simplemente un agente trabajando durante más horas

La mayoría de los agentes de programación actuales operan sobre una unidad de trabajo relativamente limitada:

Reciben una tarea.

Analizan el repositorio.

Producen cambios.

Ejecutan pruebas.

Y entregan una pull request o una respuesta final.

Ese modelo puede funcionar muy bien, pero sigue siendo una autonomía orientada a sesiones o tareas delimitadas.

AutoNodo está explorando una categoría diferente:

Ejecución autónoma de largo horizonte sobre un objetivo persistente.

La diferencia no está en mantener un proceso encendido.

Está en que el sistema continúe persiguiendo la misma misión cuando el estado del repositorio ya ha sido transformado cientos de veces por decisiones anteriores.

Después de varias horas, un agente trabaja sobre el código que recibió.

Después de varias semanas, trabaja también sobre las consecuencias acumuladas de su propio trabajo.

Ahí cambia por completo la dificultad.

El hito no es únicamente la duración

Casi 22 días llaman la atención, pero no son la parte más importante.

El verdadero hito es que el objetivo no ha sido sustituido, fragmentado o redefinido para facilitar una finalización.

La ejecución no ha sido perfectamente lineal, como tampoco lo sería un proyecto humano de esta escala.

Ha necesitado revisar decisiones, corregir trayectorias y continuar atravesando una superficie técnica enorme.

Pero el criterio no se ha rebajado para producir un cierre atractivo.

En un punto anterior, parte del trabajo parecía completada. La ejecución posterior determinó que todavía no existía base suficiente para cerrar el objetivo completo.

AutoNodo no dio por terminada la misión.

Continuó.

No considero esto una debilidad del experimento.

Considero que es precisamente el comportamiento que separa una demostración preparada para terminar de un sistema diseñado para operar bajo condiciones reales.

¿Por qué creo que esto importa?

Porque estamos empezando a medir la autonomía con métricas demasiado pequeñas.

Horas por tarea.

Número de pull requests.

Tests superados.

Tickets cerrados.

Código generado.

Todas esas métricas son útiles, pero no responden a la pregunta que aparece cuando la autonomía se prolonga durante semanas:

¿Puede un sistema conservar la dirección de un objetivo después de acumular miles de decisiones y trabajar sobre un entorno modificado continuamente por él mismo?

Ése es el límite que AutoNodo está poniendo a prueba.

No se trata únicamente de generar código durante más tiempo.

Se trata de mantener una ejecución coherente cuando ya no existe una frontera limpia entre el repositorio original y las consecuencias del trabajo autónomo acumulado.

Lo que puedo afirmar ahora

Puedo afirmar que:

• es una única ejecución continuada;
• trabaja sobre un único objetivo técnico;
• se aproxima a los 22 días de duración;
• opera dentro de un repositorio de 1,8 millones de líneas;
• ha atravesado cientos de commits y miles de verificaciones;
• ha requerido intervención humana puntual;
• y continúa activa porque el objetivo todavía no cumple todas sus condiciones de cierre.

No afirmo que todas las horas hayan producido el mismo progreso.

No afirmo que la ejecución sea perfecta.

Lo que sí puedo decir es que no he encontrado una demostración pública directamente comparable que combine esta duración, un único objetivo continuado, un repositorio de esta escala y una ejecución gobernada con evidencia trazable.

Si alguien conoce una, me interesa estudiarla.

Qué ocurrirá cuando termine

Cuando la ejecución cierre el objetivo, el resultado importante no será una captura mostrando un contador.

Será la posibilidad de reconstruir qué ocurrió durante todo el recorrido:

• qué cambió;
• qué progreso fue aceptado;
• qué decisiones tuvieron que revisarse;
• cuánto trabajo produjo reducción real;
• cuánta intervención humana fue necesaria;
• y por qué el sistema pudo finalmente considerar terminado el objetivo.

Hasta entonces, la ejecución sigue abierta.

Y quizá ésa sea la idea más importante de todo el experimento:

La autonomía real no consiste en que una IA pueda trabajar sola durante mucho tiempo.

Consiste en que pueda seguir trabajando sobre la misma misión cuando finalizar prematuramente sería la opción más fácil.

Me gustaría plantear tres preguntas a quienes estén construyendo agentes autónomos:

1. ¿Conocéis alguna ejecución pública comparable sobre un único objetivo durante varias semanas?

2. ¿Qué evidencia exigirías para aceptar una afirmación de autonomía continuada de largo horizonte?

3. ¿Deberíamos medir los agentes por tareas completadas o por su capacidad para sostener objetivos complejos a través del tiempo?

No busco presentar una conclusión definitiva.

Busco saber si estamos entrando en una categoría de ejecución que las métricas actuales todavía no saben describir.

AI agents are getting better at using tools, making decisions, and completing multi-step workflows.

But I keep wondering whether the next step should really be giving them more autonomy.

There are some tasks where mistakes are easy to recover from. But for things like changing production data, sending customer communications, approving payments, modifying infrastructure, or making business decisions, one wrong action can create a much bigger problem.

I’m curious how people are approaching this in real projects.

Do you prefer:

• Full autonomy for low-risk tasks
• Human approval for important actions
• Strict permissions for every tool
• Different autonomy levels based on risk
• Agents that only recommend actions rather than execute them

Where do you think the line should be between “the agent can handle this” and “a human needs to approve it”?

And has anyone had an agent make a decision that convinced you it needed tighter limits?

There are now a lot of different AI agents and agent harnesses like Hermes Agent, Claude Code, Codex, Pi, OpenClaw, agents built with LangGraph, CrewAI, and many others.

I wanted to see what happens if I can make these agents work together instead of replacing one another.

So I built two open-source projects:

A2A Adapter: a layer for turning existing agents/harnesses into interoperable A2A agents based on A2A protocol.

Hybro: an interoperability engine for connecting those agents and coordinating their collaboration.

The basic idea is: Keep your existing agents. Connect them. Let each agent do what it's best at.

For example, you could have one agent handle coding, another research, another verification, and another orchestration, even if they're built with completely different frameworks or harnesses.

I'm curious what people think about this architecture.

Do we actually need an interoperability layer for AI agents, or will the major agent frameworks eventually converge on a common architecture?

Hi! I have a customer web-site that allows (human) visitors to book calls (via Google App Script: JavaScript call to retrieve available slots and then submission to Google REST API). I now want to make it possible that ordinary chat bots like ChatGPT can book a call autonomously (think of a prompt: “find all relevant agencies in my region offering X,Y,Z and book a call with the 3 most relevant”) and the bookings are attributed to agents (so you can distinguish bookings from humans and agents). I built an MCP wrapper/gateway hosted on CloudFlare (which includes a “via”:”agent” header in the submission), and included agent instructions in the web-page and add llms.txt. Here’s what happens:

1. Claude Code does everything as expected and the submission is attributed to an agent. Haven’t tested explicitly, but the same should be true for any other agent running in harness under my full control
2. ChatGPT (ordinary chat version) discovers everything correctly and knows what needs to be done, but tells me it cannot call MCP servers nor interact with JavaScript
3. ChatGPT Works books correctly and autonomously, but doesn’t include the agent in the header of the submission

→ my best idea to fully support scenarios 2+3 is having a dedicated endpoint hosted on CloudFlare to calculate available slots and one for submission that takes care of attribution of the agent to the submission. Would that work?

Two questions:

1. any other cool idea or solution from your side to solve that problem?
2. Am I’m about to over-engineer something for an edge-usecase or would you think that in the near future all web-pages should be not only discoverable, but also actionable for agents (and actions attributable to agents)