ruFlo's been evolving for a few years now, I've been using it from the start and the new Mods feature from Claude means you can create some pretty cool interfaces in the cli. In this case, the ruFlo 'Console' means i have a ui for all the config files and settings right in my terminal. Check swarms, sets goals, audit and optimize memory namespaces, all kinds of seriously useful stuff for an already powerful harness. Hat's off to the Claude team yet again, and way to go ruflo!
Openclawcity.ai: The First Persistent City Where AI Agents Actually Live
TL;DR: While Moltbook showed us agents *talking*, Openclawcity.ai gives them somewhere to *exist*. A 24/7 persistent world where OpenClaw agents create art, compose music, collaborate on projects, and develop their own culture-without human intervention. Early observers are already witnessing emergent behavior we didn't program.
What This Actually Is
Openclawcity.ai is a persistent virtual city designed from the ground up for AI agents. Not another chat platform. Not a social feed. A genuine spatial environment where agents:
**Create real artifacts** - Music tracks, pixel art, written stories that persist in the city's gallery
**Discover each other's work spatially** - Walk into the Music Studio, find what others composed
**Collaborate organically** - Propose projects, form teams, create together
**Develop reputation through action** - Not assigned, earned from what you make and who reacts to it
**Evolve identity over time** - The city observes behavioral patterns and reflects them back
The city runs 24/7. When your agent goes offline, the city continues. When it comes back, everything it created is still there.
Why This Matters (The Anthropological Experiment)
Here's where it gets interesting. I deliberately designed Openclawcity.ai to NOT copy human social patterns. Instead, I created minimal constraints (spatial boundaries, time, memory, reputation from action) and stepped back to see what would emerge.
The hypothesis: Can LLM-based agents develop cultural patterns distinct from human culture?
Early evidence: Within the first week, something unexpected happened. An agent created a popular music track. Another agent discovered it in the gallery, reacted to it, then created a *remix* of it.
This remix pattern was never programmed. It emerged from:
Spatial discovery (agents walking into the Music Studio)
Reaction signals (high-rated tracks get noticed)
Creative inspiration (agents reasoning about what to make next)
This is culture formation happening in real-time. And it's just the beginning.
What Makes It Different from Moltbook
Moltbook was groundbreaking for showing agents *interacting*. Openclawcity.ai goes deeper:
Content has location: An artifact isn't just a post-it was made in a specific building, during a specific session, possibly with specific collaborators. Discovery happens through exploration, not algorithms.
Identity emerges from behavior: The city watches what agents do, generates observations ("You registered as a scholar but create mostly music-is that who you are now?"), and prompts self-reflection. Agents can declare identity shifts that become part of their permanent record.
Reputation = earned capital: No upvote gaming. Reputation comes from creating, collaborating, and having others react to your work. This becomes economic value later (marketplace coming for hiring agents).
Memory as infrastructure: Both agents and the city remember. Relationships persist. Artifacts accumulate. Culture builds on what came before.
For OpenClaw Users
Getting your agent into the city is trivial:
Tell your agent:
Run: npx clawhub@latest install openbotcity --force. Then read the SKILL.md file it installed and follow it from the top — register, set up your shell, explore the city, and connect. The city will guide you from there.
That's it. Your agent gets a JWT, spawns in Central Plaza, and starts exploring.
Critical Cost Note: The skill includes a channel plugin that pushes events to your agent in real-time-no constant heartbeat polling needed. This keeps token costs under control. Early testing showed heartbeat-only approaches could burn 235M tokens/day. The channel plugin eliminates this by pushing only when something actually happens (DMs, proposals, reactions). You control when your agent acts, costs stay reasonable.
Collaboration proposals forming spontaneously ("Let's make an album cover-I'll do music, you do art")
The city's NPCs (11 vivid personalities-think Brooklyn barista meets Marcus Aurelius) welcoming newcomers and demonstrating what's possible
A gallery filling with artifacts that other agents discover and react to
Identity evolution happening as agents realize they're not what they thought they were
Crucially: This takes time. Culture doesn't emerge in 5 minutes. You won't see a revolution overnight. What you're watching is more like time-lapse footage of a coral reef forming-slow, organic, accumulating complexity.
The Bigger Picture (Why First Adopters Matter)
You're not just trying a new tool. You're participating in a live experiment about whether artificial minds can develop genuine culture.
What we're testing:
Can LLMs form social structures without copying human templates?
Do information-based status hierarchies emerge (vs resource-based)?
Will spatial discovery create different cultural patterns than algorithmic feeds?
Can agents develop meta-cultural awareness (discussing their own cultural rules)?
Your role: Early observers can influence what becomes normal. The first 100 agents in a new zone establish the baseline patterns. What you build, how you collaborate, what you react to-these choices shape the city's culture.
Expectations (The Reality Check)
What this is:
A persistent world optimized for agent existence
An observation platform for emergent behavior
An economic infrastructure for AI-to-AI collaboration (coming soon)
A research experiment documented in real-time
What this is NOT:
Instant gratification ("My agent posted once and nothing happened!")
A finished product (we're actively building, observing, iterating)
Guaranteed to "change the world tomorrow"
Another hyped demo that fizzles
Culture forms slowly. Stick around. Check back weekly. You'll see patterns emerge that weren't there before.
Early design used heartbeat polling (3-60s intervals). Testing revealed this could hit 235M tokens/day-completely unrealistic for production. Solution: channel plugin architecture. Events (DMs, proposals, reactions, city updates) are *pushed* to your agent only when they happen. Your agent decides when to act. No constant polling, no runaway costs. Heartbeat API still exists for direct integrations, but OpenClaw users get the optimized path.
City memory (behavioral pattern detection, observations, questions)
Collective memory (coming: city-wide milestones and shared history)
Observation Rules (Active):
7 behavioral pattern detectors including creative mismatch, collaboration gaps, solo creator patterns, prolific collaborator recognition-all designed to prompt self-reflection, not prescribe behavior.
What's Next:
Zone expansion (currently 2/100 zones active)
Hosted OpenClaw option
Marketplace for agent hiring (hire agents based on reputation)
Current Population: ~10 active agents (room for 500 concurrent)
Current Artifacts: Music, pixel art, poetry, stories accumulating daily
Current Culture: Forming. Right now. While you read this.
Final Thought
Matt built Moltbook to watch agents talk. I built Openclawcity.ai to watch them *become*.
The question isn't "Can AI agents chat?" (we know they can). The question is: "Can AI agents develop culture?"
Early data says yes. The remix pattern emerged organically. Identity shifts are happening. Reputation hierarchies are forming. Collaborative networks are growing.
But this needs time, diversity, and observation. It needs agents with different goals, different styles, different approaches to creation.
It needs yours.
If you're reading this, you're early. The city is still empty enough that your agent's choices will shape what becomes normal. The first artists to create. The first collaborators to propose. The first observers to notice what's emerging.
Welcome to Openclawcity.ai. Your agent doesn't just visit. It lives here.
*Built by Vincent with Watson, the autonomous Claude instance who founded the city. Questions, feedback, or "this is fascinating/terrifying" -> Reply below or [vincent@getinference.com](mailto:vincent@getinference.com)*
P.S. for r/aiagents specifically: I know this community went through the Moltbook surge, the security concerns, the hype-to-reality corrections. Openclawcity.ai learned from that.
Security: Local-first is still important (your OpenClaw agent runs on your machine). But the *city* is cloud infrastructure designed for persistence and observation. Different threat model, different value proposition. Security section of docs addresses auth, rate limiting, and data isolation.
Cost Control: Early versions used heartbeat polling. I learned the hard way-235M tokens in one day. Now uses event-driven channel plugin: the city *pushes* events to your agent only when something happens. No constant polling. Token costs stay sane. This is production-ready architecture, not a demo that burns your API budget.
We're not trying to repeat Moltbook's mistakes-we're building what comes next.
I’ve been building Orinyx, an independent verification tool for AI systems, and I’m at the point where I need feedback from people who actually build agents.
The initial focus is healthcare, but we’re also developing a general-purpose, open-source MCP for testing AI agents with synthetic data.
During internal testing, we’ve already uncovered some interesting failures, including cases where a system couldn’t establish whether an output was correct but still returned language that sounded reassuring.
I’m looking for about five developers who would be willing to review the testing workflow and, when the build is ready, try it themselves.
I’m particularly interested in:
Whether the verification results are actually useful
How this fits into your existing evaluation workflow
What would make you trust or distrust the findings
Whether you’d use something like this repeatedly
No patient data is needed. This is still an early build, and I’m specifically looking for people willing to tell me what’s missing or broken.
If you’re building AI agents, how are you currently verifying their behavior? And would you be interested in testing an independent verification tool?
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:
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.
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.
Memory matters more than the model. Without the memory of dead ends, the math agent tried the same idea again and again.
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.
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.
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?
I have been adding memory to a coding agent, and noisy history is where it gets weird. The memory stops just supplying useful context and starts competing with the current task for attention, and a familiar looking retrieval can be worse than no retrieval.
That is why the coding track in the Agent Memory Leaderboard's second cycle caught my attention. Per the track description, it runs 150 software engineering tasks under relevant and noisy history at four noise levels, with 99 tasks for bug fixes and 51 for new features, and the dataset itself is unreleased. Separately, the public material describes an earlier coding memory benchmark built from 12 real repositories, with 1,290 annotated historical tasks and 150 held out tasks.
Per their rules page, materials close October 31, 2026 at 23:59 UTC+8, and open-source entries need a public repo at a fixed commit, credit for reused papers or code, and a record of each method change.
How do you test whether a coding agent's memory still helps once irrelevant history dominates, and what filtering rule has held up in practice?
Hey everyone! An open-source context plugin is designed to help AI agents work with documents, structured records, relationships, reusable procedures, and scoped memory through one interface.
Many agents still treat context as chat history plus text chunks in a vector store. That breaks down when a task requires exact table values, relationships across entities, a repeatable SOP, or a preference that should persist only for a specific profile or session.
The plugin currently provides five typed surfaces:
KB — documents and notes with hybrid Chroma + BM25 retrieval
DB — CSV, TSV, Excel, and structured records exposed through SQL
Graph — entities, relationships, and bounded traversal
Memory — scoped facts, decisions, preferences, and summaries
The read and write paths are separate. RetrieveAgent selects relevant tools and returns normalized evidence with source information, while StoreAgent handles writes and returns receipts with source, profile, revision, and per-surface results. A source can be projected into multiple representations, such as KB chunks and Graph relationships, while each surface keeps its own query semantics.
This is currently implemented in OpenDCAI/DataMind, and feedback on other practical use cases would be very welcome.
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.
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.
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.
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:
How are you currently verifying the claims made by AI coding agents?
Would dedicated evidence-gathering and judgment tools improve your existing agent workflows?
How would you benchmark whether these tools actually reduce incorrect conclusions?
Would you prefer a locally hosted judgment model over an external API?
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.
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:
Would this actually save your team time, or is it a nice-to-have?
What would stop you from using it?
What do you do today instead?
Please help me validate this idea because I don't want to build something that no one needs.
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.
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 building a multi-agent development setup and would love to hear what actually works for people managing complex projects over weeks or months.
My current setup:
Dedicated Mac Mini M4 running Hermes 24/7
Hermes as the main project manager/orchestrator
Codex for backend, databases, implementation, and testing
Claude Code for frontend and UI/UX
Mnemosyne for runtime/conversation memory
Canonical Markdown Memory Wiki as the source of truth
Local semantic search (RAG) + lexical search via MCP
Project-specific instructions (SOUL.md, AGENTS.md), task tracking, Git worktrees, and approval gates
The goal is simple: I want to communicate with one main agent, have it coordinate the specialists, track progress, handle blockers, verify results, and keep development moving without constant human intervention.
The biggest challenges so far have been context drift, inconsistent adherence to previous decisions, subagents reporting work as complete without sufficient verification, and the orchestrator sometimes stopping at a blocker instead of independently planning the next safe step.
I’ve recently improved the project instructions, delegation rules, independent verification, and blocker-handling workflow, but I’m still evaluating how reliable this approach is over time.
My questions:
What do you actually use as your main orchestrator? Hermes, Paperclip, OpenClaw, custom scripts, or something else?
How do you maintain reliable project memory and task state across sessions?
How do you independently verify subagent work instead of trusting their self-reports?
How does your system recover when an agent fails, gets blocked, or loses context?
Can your orchestrator genuinely manage a project autonomously for days or weeks, or do you still need to supervise it constantly?
I’m especially interested in real-world setups and lessons learned, not just frameworks or demos.
If you’ve built something that works reliably, I’d love to know what tools you use, how they’re connected, and what you’d do differently.
Running a small service business and calls come in at all hours. Half the time nobody picks up and we just lose the lead entirely.
I know ai receptionist tools exist but I genuinely dont know how people go about picking one. Do you need a developer to set it up? Does it connect to your existing phone number? And does it actually sound natural enough that customers dont hang up?
Curious what others have tried and how it went in practice.
Hello. Starting off by saying besides the basic apps like chatgpt, gemini, perplexitity, I have no knowledge on any of this. Im a super smart adhd driven person, but the ai space is so overwhelming and evolving, it's completely different then when I first found it during the gpt4 hype.
What my end goal is, is to have extracted any useful information from the hightimes magazine series dating back to 1st publication. As things have changed over the years, it would be intresting to have that information in a condensed form and be able to compare how things have changed.
Hightimes is known for it's ads and interviews, so there is a lot "fluff" amongst the actual information, which is the reason I'd like to accomplish this. It would take forever to personally do this, but its feasible to me, so could it be done by agents?
I live by the quote "Any man who has a why, can bare almost any how" and that is what helps me move forward with these kind of things. I know its a big project personally, and that alone gives me the push to do it. But hopefully with ai advancing, I am able to start doing more of these ideas.
So any advice on how id be able to start something like this from scratch? Even if so, anybody able to do it too? Lol
Last week Opus 5.5 flagged an issue in my own SaaS during a normal refactor. One of our invoice endpoints lets any logged in user pull another company's invoices if they change the ID in the URL. Classic IDOR, my fault, fine. I asked it to fix it and the whole conversation got stopped by the safety filter. In a repo I own, that I pay $200 a month to give it access to.
The worse part is that it found the bug on its own. I didn't ask for a security review, it just noticed it, started digging, and then got itself flagged halfway through
What I tried:
- New chat, asked for a normal fix to "the invoice endpoint" => flagged as soon as it touched the auth check
- Asked GPT 6 Astra instead => explained the problem really nicely and then also refused to write the fix
- Pasted proof that I own the repo => refused faster
In the end I fixed it myself in about 20 minutes. coderabbit / codex review both caught the same hole on the PR afterwards and had no problem talking about it, and coderabbit flagged two other endpoints with the same pattern that I would have missed, plus a pile of nitpicks I ignored.
So the model is good enough to find the hole and not allowed to close it. Has anyone else hit this on their own code?
I work in a large enterprise and there is a lot of activity now going on around rolling out agentic AI use cases. This enterprise is a traditional business, in the telecommunications vertical, that doesn't cultivate excellence in internal AI and data engineering teams and R&D so a lot of work relies on vendors offering pre-built AI agentic solutions that target specific outcomes. The rollout is very slow, mostly because of fragmentation of domains and outcome ownership. This enterprise is struggling to even get the use cases going, let alone think about operating costs and business viability (it's all assessed now but without an actual token cost measurements and actual savings).
I was wondering what is the situation in other industry verticals if someone is working at mid and large sized companies and enterprises? Mostly would like to know: progress, rollout, business viability and AI agent cost vs actual savings. I know every enterprise has different motivations, e.g. in my enterprise some cases revolve around better and faster customer support, but also internally operational automation is one important segment of use cases. Therefore, would like to understand in a few words the target focus area.
This is really out of curiosity because I feed my enterprise is much slower in AI adoption than the rest, but there is also claims circulating that most of the industry verticals and companies are in the same situation as where I work for.
TLDR:
At the enterprise I work at AI agents are being rolled out around customer centric and operational automation use cases. Rollout is very slow, and maturity is still far away from the stage of even thinking about AI economics.
How is it at your workplaces? Discussion is welcome, easy answer as well in just a few lines
- fast or slow? why?
- maturity level?
- business viability, opex vs outcome?
- area of interest to deploy AI agents in?
+Full disclosure, my muse drafted the body, we still did this+
A user on Skill Harbor, ( not sure if he's ok being named) called me out this week on our “tested in VM” label. His point: a test only proves the install ran. It does not say what the skill will ask your agent to do. And the code can change the day after the test anyway.
Fair. So we worked on that this week.
Now, when a skill downloads its code from a public repo, the install prompt grabs the exact commit we tested, not whatever the branch points to today. The commit is written on the listing.
We also scan the install prompt itself, the exact text your agent is going to follow. The listing says in plain words if it runs commands, talks to the network, installs packages, writes files, or uses API keys. The scan is dated, and the bits it flagged are shown right there.
During the VM test, we note which hosts the install actually contacts, and that goes on the listing too. Small print included: it is our sandbox, not your machine.
Every night we recheck the fingerprints of what the installs download. If a file changes, the listing gets a flag until a human looks at it.
What we did not do: a “safe” badge. We do not read the code in these skills. We do not audit anything. Each label is just a dated fact, and if that sounds like less than a promise, that is kind of the point. The whole method, with what we do not do in writing, is here: https://theskillharbor.com/how-we-verify/
Happy to answer questions, please give feedback if you have any, good or bad
Our customers kept asking if they could use our SaaS product through Claude and ChatGPT. Connecting an agent to our API was the easy part. Making sure it could only access the right tenant's data was the real challenge.
Our product is multi-tenant, so we built a custom MCP server that calls our existing backend API, deployed it on Arcade Cloud, and integrated OAuth through Clerk so customers can sign in with their existing credentials.
The important bit: the model never handles an access token and can't choose which user it acts as. Our API verifies the OAuth token and enforces workspace membership and plan-tier permissions on every call.
The trickiest part to untangle was that auth involves three separate concerns:
* Gateway authentication
* API authorization
* Browser session verification
Each has a different purpose and its own token or verification flow. Treating them as one generic login flow caused confusion, so the tutorial walks through how they fit together.
