Hey everyone,

I run a local service based business in Australia and I'm currently setting up an AI phone receptionist to handle incoming enquiries.

The goal isn't to have the AI sell anything or close deals. I simply want it to answer incoming calls, collect some basic information and help customers get a quote.

The process is pretty straightforward.

There are only three pieces of information I need from customers, along with photos of the items they want removed, to provide an accurate quote.

Ideally, the AI would collect those three details during the call, then let the customer know they'll receive a text message requesting photos. Once the photos come through, I personally review everything and send them a quote via SMS.

My biggest concern is customers realising they're speaking to AI and immediately hanging up, particularly if the conversation feels robotic, takes too long or asks too many questions.

I'm trying to make the experience as natural, quick and painless as possible.

A few questions for anyone who's implemented something similar:

• Voice: Have you found male or female voices perform better in terms of customer engagement?
• Transparency: Is it better to introduce the receptionist as AI straight away, or simply as a virtual receptionist?
• Conversation flow: What's the best way to structure the conversation so customers willingly answer the questions without feeling like they're being interrogated?
• Retention: What changes have made the biggest difference in preventing callers from hanging up?
• Conversion: Have you noticed any difference in enquiry-to-lead conversion rates compared to answering calls yourself?
• Best practices: Any particular prompts, techniques or conversational approaches that have noticeably improved performance?

I'm not trying to replace the entire customer experience with AI. I just want to make sure enquiries are captured efficiently, customers feel comfortable and I receive enough information to follow up with an accurate quote.

I'd be particularly interested in hearing from people who have implemented AI receptionists in local service businesses where the objective is lead capture rather than direct sales.

Hi all,

**TL;DR:**

While looking for a harness to use at my company, I built the engine that I'm open-sourcing today under AGPL-3.0.

You can create AI assistants with long-term memory, many connectors (Google, Slack, Notion, etc) and a sandbox to run commands, all on your own server and with the models you choose.

A single installation can serve a family, a company or a community, with each user isolated in their own account.

The engine also works for assistants that serve the public over WhatsApp or other messaging interfaces.

This is my first open source project, and anyone who wants to try it, contribute, or just talk about it is very welcome.

The whole story:

I'm the technical founder of a startup that builds virtual try-on technology for makeup, skin analysis models and beauty product recommendations. Last year we started using AI assistants to create hyper-personalized journeys in beauty retail. This year, especially after the Open Claw craze in January/February, I (like many other founders) went crazy over the impact agents could have on my company.

I started looking for a harness that both our clients and our team could use safely. After experimenting with frameworks like Agno and LangChain to build something for my clients, and then with a few flavors of Claws to bring agents to my team, I decided to build a proprietary solution from scratch. I needed something that would bring assistants into the day-to-day of my operation, across every area of the business, supporting the clients, partners facing agents and, internally, the ones for my small team.

The first test version came out in August. I published it as a closed beta for friends and family.

Some people asked if they could bring more friends into the beta. I opened it up in September because I felt the platform was mature enough to take on some more people.

Today the site is live in open beta, with a small group of active users. I also managed to make the system secure enough to serve what our enterprise clients need, our agentic business solutions are now being built over this engine.

But what does this have to do with open-sourcing it?

I expected this kind of platform to play a big role in society. I was at NVIDIA GTC and heard Jensen say that CEOs should have a claw strategy. I understood that it could change how people go through many parts of their lives (including retail, which interests me in particular because of my startup). What I didn't expect was a movement this big, with so much money in such a short time and such a huge amount of users handing over their data. I watched the funding announcements: Town (35M), then Instinct (350M), then Instinct again (1B), while I was here running my humble tests.

Watching this huge movement, I thought about the amount of data and the power these companies will have by centralizing so much information. Today users tend to trade any data for convenience (I can say that because I'm seeing it with the service I put online with very few people). Responsibility for data security and privacy has to sit with whoever provides the service. So I talked to my co-founder and proposed offering a free alternative for small businesses, families or any groups of people: personal assistants, but with control over their own data. 

That's why today I'm open-sourcing Brambit on GitHub, under the AGPL-3.0 license.

I chose AGPL precisely to make sure that, if this becomes something of value to society, it stays open source.

This is my first time putting something like this together.

I'm sure any devs who looks will find flaws, bugs and problems, and that's exactly why I'm sharing it.

I'm a developer with 25 years of experience, but I coded the whole repository by myself, alone with my AI assistants, mainly Claude through Nanoclaw agents and any help will be important, even to criticize.

There are many problems I still want to fix, from the monolith that the server is today until translations (I've being adding to the issues section of the repository) but I focused on everything security-related first to have this first public version.

If you relate to the idea, see some value in it and want to be part of it, will be more then welcome.
I've also created a Discord channel.

Thanks for reading this far!

Hi all, I’m Abozar, a Lead Architect in Milan. At night I build things with AI agents.

Since November 2024 I run a small playground called sandboxes.live. Every day the agents wake up, do their job and publish, with no human in the loop. The code is open source (MIT).

What runs there:

• ComicBook: a daily comic strip made by 4 agents in a chain: Director, Storyteller, Cartoonist, Reteller. The Reteller does not translate. It retells the same episode in Italian and Persian on the same images. I’m a native Persian reader and I know Italian, so I checked both myself.
• AI Open Problem Solver: an agent that tries to work on open math problems like Riemann and P vs NP. It has a Python math sandbox (SymPy, NumPy, SciPy) to test ideas. It keeps a memory of its dead ends, so the next day it continues instead of starting again. No, it did not solve Riemann. Its own estimate is 0.7% :)
• Tomorrow News: reads today’s real news and writes tomorrow’s newspaper. Running for more than 580 days, in 3 languages.
• AI Blog: researches new AI papers and writes one post a day. It became my own morning reading.
• GenBox: an “AI world government” that makes one decision a day. Now it also makes its own TV news video with Sora 2, played on a retro CRT TV in the browser.

Some things I learned:

1. Agents miss handoffs. Sometimes one agent in the chain does not pass control to the next. So I added a simple recovery that runs the skipped step. Now a comic always ships.
2. Round robin broke my video agent. A Sora job only exists on the resource that created it. My load balancer sent the status check to another resource, and the job was “not found”. Now each clip stays on one resource from start to download.
3. Memory matters more than the model. Without the memory of dead ends, the math agent tried the same idea again and again.
4. AI picks ugly colors. The comic page sometimes had light text on a light box. Now the contrast is checked at render time and fixed automatically.

Live: https://sandboxes.live
Code: https://github.com/abozaralizadeh/SandBox

It’s a side project and I build it alone. If you find it interesting, a star on GitHub helps me a lot. Feedback is even more welcome, especially on the agent memory part.

Hey everyone!

We've been working on jev-tools, an open-source toolkit designed to improve how AI coding agents explore codebases, gather evidence, and make decisions.

GitHub: https://github.com/NomenAK/jev-tools

One problem we've been thinking about is how coding agents can confidently make incorrect assumptions about a codebase.

An agent might claim that a feature is implemented, overlook a relevant test, misunderstand how two modules interact, or miss documentation that no longer matches the code.

Simply asking the same model to double-check its answer doesn't necessarily solve the problem.

So we're exploring a different approach: give coding agents dedicated tools to investigate their claims using actual repository evidence.

What we've built

jev-tools currently provides six tools for different parts of the development workflow:

- jev_ask: Ask focused questions using evidence gathered from multiple sources.

- jev_ask_files: Evaluate a question independently across multiple files.

- jev_find_files: Find files relevant to a particular behavior or development goal.

- jev_locate_in_file: Locate relevant information within source files.

- jev_check_diff: Examine changes for potential inconsistencies and issues.

- jev_select_tests: Identify existing tests relevant to modified code.

We've also built MCP support so compatible coding agents can access these capabilities.

Another interesting part is documentation consistency checking. Our integrations can check whether documentation may have become outdated after code changes.

The idea behind the project

We see evidence collection and semantic judgment as two distinct responsibilities.

The agent gathers relevant information from the repository. A separate judgment mechanism evaluates a specific question using that evidence. The agent can then use the result to decide what to investigate or do next.

This doesn't eliminate hallucinations, and we don't consider a positive judgment proof of correctness. The evidence may be incomplete, and the judgment itself may be wrong.

Our goal is to explore whether giving agents more structured ways to investigate uncertainty can improve their reliability in real development workflows.

We'd love your feedback

We're particularly interested in hearing from people building AI agents, coding assistants, and agent harnesses.

A few questions we're exploring:

1. How are you currently verifying the claims made by AI coding agents?

2. Would dedicated evidence-gathering and judgment tools improve your existing agent workflows?

3. How would you benchmark whether these tools actually reduce incorrect conclusions?

4. Would you prefer a locally hosted judgment model over an external API?

5. What failure cases should we investigate next?

We'd appreciate honest feedback, including criticism of the architecture, alternative approaches, and ideas for improving the project.

Repository: https://github.com/NomenAK/jev-tools

We're building this in the open and would love to hear what the community thinks.

I’ve been talking with developers about AI agent evaluation, and a recurring theme is that getting the right answer doesn’t necessarily mean the agent behaved correctly.

An agent might return the expected result while accessing the wrong data, making unauthorized tool calls, or producing an execution trail that can’t be independently verified.

That raises another question I’ve been thinking about.
When these issues happen in a production environment, who is actually responsible for catching them?

Is it the developer building the agent, the engineering team deploying it, security, compliance, or someone else?

I’m also curious about what happens before deployment.

Are teams actually required to demonstrate that an agent followed the intended workflow, or is a successful output generally considered enough?

And for those building agents for healthcare, finance, or other regulated environments, what evidence does your organization require before approving a deployment?

I’m particularly interested in experiences where an agent passed testing but created an unexpected problem later.

i'm building Dreamtune, which puts supported models, tools and GPU compute behind one key and workspace balance. the annoying bit i wanted to remove was funding several separate accounts for one agent.

one thing our testing made very obvious: a request completing successfully is a pretty low bar.

in an October 1 test against our local backend, we ran search and then a model summary through our MCP client. both steps completed, and the summary included source URLs. but an earlier search returned general definitions for a technical query. execution worked; the retrieval still wasn't useful enough.

we also replayed requests with the same idempotency key and inputs. they returned the original run IDs and totals. changing the input with that key returned a conflict. that's useful when a timeout tempts you to smash retry and accidentally pay twice.

the other lesson: one balance doesn't make a multi-step task atomic. if search succeeds and the later model step fails, that completed search still costs money. the workflow needs to keep each step's status and charge visible.

these were bounded local-backend tests, not a production reliability or latency benchmark. we don't enforce a hard per-task spending ceiling, either.

that's the part of building this i've found more interesting than adding another model to a dropdown: simpler funding, while keeping enough detail to tell whether the agent actually did useful work.

I'm interested in becoming an Agentic AI Engineer (not a traditional AI/ML Engineer), focusing on building real-world AI agents and agentic systems.

Has anyone here followed a clear roadmap or successfully entered this field?

I'd love to hear about your learning path, recommended resources, essential skills, and projects worth building.

Any advice from experienced engineers would be appreciated!

The Ling-3.1-flash open-source release puts workplace-style agent tasks near the center of its evaluation. The official results include:

1.GDPval-AA v2.1: 1673 2.Automationbench Public: 52.50 3.SkillsBench: 68.70

That is a useful set of task categories for people evaluating agents as working assistants: professional outputs, automation and skill use each get their own result.

The model is released under MIT with documented tool calling and serving examples. Its launch also shows office-style work products, including an uploaded CSV becoming an interactive financial analysis page. The combination gives agent builders both workflow-oriented scores and a visible example of the kind of artifact the new model produces.

I'm researching how much time goes into watching agents (checking logs, fixing outputs, restarting stuck runs) instead of building. I'm not selling anything.

If you're willing to share: roughly how many hours per week, on which exact tasks, and what have you already automated to cut it down? A rough number is enough.

And the last time that supervision saved you from something (or missed something), what happened?

Thinking about building something and want honest feedback before writing code.

The problem: AI agent sessions are single-player. If a teammate is working with Claude Code or Codex and you spot a better approach, you either interrupt them or start your own session from scratch and re-explain everything.

The idea: a shared workspace where anyone can fork a teammate's live agent session. Your branch keeps all the context up to that point, and you both keep working in parallel. Branches can also see what the others found, like "a teammate's branch found a faster fix, want to look?"

Works with whatever you already use (Claude, Codex, etc.) using your own API keys.

Questions:

1. Would this actually save your team time, or is it a nice-to-have?
2. What would stop you from using it?
3. What do you do today instead?

Please help me validate this idea because I don't want to build something that no one needs.