Ardent, a code-first agent for non-engineering work
I’m Nate, the founder of Ardent. We just shipped our public beta, and we’d love your thoughts! Ardent is an agent running in a desktop (Electron) app built to help with knowledge work, designed for less-technical people outside engineering. Think Codex or Claude Cowork, but built around collaboration and customization. I know, I know, it’s yet another agent harness! Ardent is a little different – it leans heavily on codegen to solve problems. Most agents are basically just a bag of tools and a while loop, but Ardent writes code to complete tasks, making it much faster and more token-efficient. [0] Lots of companies are trying to build their own agent harness right now, because token budgets make software appear cheap, and it seems like a competitive advantage to own a custom agent. The thing is, agents are deceptively complex. They aren’t light wrappers around the model anymore; the harness makes a big difference in how capable the agent is. They also come with lots of sticky problems: context management, sandboxing and permissions, authz/authn to remote services, etc. Instead of building your own harness from scratch, you can customize Ardent using abilities: TypeScript libraries that can expose tools and prompts which can be used by the agent. They’re like agent skills, but closer to regular code libraries: type-safe, importable, and with well-defined permissions. Ardent can help you build abilities, but you can also create them by hand if you prefer. Anyone can share abilities with everyone in their organization with a single click, and if Ardent notices that the user is doing repeatable work, it offers to transform the adhoc solution into a reusable ability. Say you prepare the same project update every Friday, pulling issues from Linear and docs from Google Drive. Ardent can turn that workflow into a reusable ability that you can share with everyone in your company. Your company’s ability catalog is like a standard library. To solve a problem, Ardent searches for existing abilities, and then writes glue code to compose them. Because the code is ephemeral, it doesn’t need to be maintainable, which lets us use cheaper, less-capable open weight models like Kimi and GLM. [1] Code executes on the user’s machine in a Deno sandbox with zero permissions by default. Abilities declare required permissions up front, and any code that exceeds the current scope gets terminated and prompts the user for approval. Ardent can also connect to a bunch of tools which you’re already using, like Google, Linear, and so on. We support MCP servers, but in our experience, MCP is slow, token-expensive, and provides a pretty bad experience for both agents and users. [2] Instead, Ardent connectors handle auth, but instead of using MCP, we generate client shims which call the service’s primary API. This is a much better fit for Ardent’s codegen approach, because the agent can read the client and treat it like any other library. There’s a bunch of other interesting stuff in Ardent: memory, conversational recall, scheduled tasks, prompt suggestions, and so on. During our beta period, we’re selling inference at-cost, and we’re giving each organization some free credits to experiment. Please take a look and tell us what you think! We’d love your feedback, whether you think what we’re doing is good, bad, or meh. I’m also happy to answer any questions that you might have. --- [0] Cloudflare has taken to calling this “code mode”: https://blog.cloudflare.com/code-mode/ [1] In our benchmarks, Ardent consumed 63% fewer tokens than Opus running in Claude Cowork, with half the model requests. [2] MCP servers rarely define input/output contracts, and it’s hard to write code that calls a function when you don’t know its arguments, or even its arity! Here's a good read on the subject: https://www.blacksmith.sh/blog/code-smith-code-mode
AI-анализ
Анализ скоро появится.
Похожие продукты
Transfer.zip
Самый простой способ отправить файлы. Отправляйте 100 ГБ+ бесплатно — без лимитов, данные зашифрованы. Быстрый и безопасный обмен файлами.
Cogram Studio
Hi HN, Rick and Alex here, co-founders of Cogram. We’ve been making project-management software for architects and engineers since 2023, and are now experimenting with a second product. Cogram Studio (studio.cogram.com) is a CAD and BIM workspace for AI agents to create three-dimensional models and dimensioned drawings. Studio runs FreeCAD (https://github.com/FreeCAD/FreeCAD) 1.1 headlessly, using the OpenCASCADE (https://github.com/Open-Cascade-SAS/OCCT) geometry kernel. It imports and exports STEP, IFC, STL, DXF and FCStd files. Studio exposes an MCP server, so you can operate it from Claude Code, Codex, ChatGPT, or other agents. Tools cover scripting against FreeCAD, inspecting the model visually, CRUD operations on views, tables, and sheets, importing terrain, etc. Studio also provides a built-in agent based on Pi (https://github.com/earendil-works/pi) and a basic UI for 3D model inspection, measurement, view, table, and sheet creation. There are two ways to try it: 1. Bring your own agent. Point Codex or Claude Code at studio.cogram.com/skill.md and ask it to follow instructions there. This starts a one-hour Studio session and opens the modelling environment in your browser, connected to your agent. You need to confirm sign up only if you want to save the session. 2. Use Studio’s built-in agent. Submit a prompt at studio.cogram.com and sign up. You receive 50 free credits. Here are two models created by agents: - A simple bookshelf (https://studio.cogram.com/view/shr_1agb21nd4) with two sheets - The Colosseum (https://studio.cogram.com/view/shr_3tm32c64y) [large, can take minutes to load], with two sheets showing dimensioned and annotated views. For now, Studio works best when you use it iteratively. If you ask an agent for a finished, complex model and “let it rip”, it may produce something that looks convincing but doesn't hold up to scrutiny. Agentic modelling feels roughly like where agentic programming was in 2024: useful for speeding up repetitive or bounded tasks but not yet reliable enough to complete long, complex jobs. Recent models have improved at CAD. We expect progress to accelerate as models become even better at reasoning across the different representations used in architecture and engineering: geometry, drawings, images, materials, physical constraints, specifications, regulations, code, etc. Early users and our own experience suggest that agents are already useful design collaborators. They can help with repetitive CAD work, fabrication options, part sourcing and cost estimates. We expect that as models improve, agents will be able to explore many different designs, run simulations, and check constraints across an entire project. CAD will become a shared workspace for humans and agents. Because design decisions made in CAD shape much of what is eventually built, even modest improvements could have wide effects. We’d love to hear your feedback and ideas if you give Studio a try. We’re also hiring across product, engineering and commercial roles. If you’re interested in working on interesting problems involving AI and the physical world, please take a look at our open positions at https://cogram.com/about#careers.
Cushion
This project mostly came from knowing that Deno KV is backed by FoundationDB and that there were (are?) plans to use Foundation for CouchDB 4.0 too. I like working on Deno. I like working in CouchDB. I like Deno KV but don’t enjoy the ergonomics of it. So Cushion was mostly made for my comfort. PouchDB with Deno KV as the storage adapter.
I built a tool showing how AI providers (should) throttle their models
OP here: this project was born out of the frustration/paranoia that AI providers are throttling their models when their server load is too high. So, I set out to model and study the problem mathematically to understand what was happening, what I found was quite surprising. The idea seems natural: as the data center demand increases momentarily through the day, throttling their models (either using quantized versions, reducing the context window or lowering the tier of the model to a smaller one) seems appealing as the replacement model in principle uses less electricity. The problem is that this can cause the opposite effect: as users are trying to solve a question, if the degraded AI model gives a bad answer, the user is likely to keep re-asking. On the AI provider side this looks paradoxical: throttling to a lower model creates in fact more demand for their data center. This problem is even worse for agentic workflows, as these are more likely to create a re-ask storm, and maybe explains the outages and anecdotal experiences of users that feel the models are degraded. The model: I used mainly queueing theory arguments solving the optimal scheduling serving for an AI fleet with heterogeneous users solving a finite horizon Dynamic Programming optimization problem. Insights: The industry standard practice of throttling once the number of users in system exceeds a given threshold is in fact what’s causing the problem, the optimal rule implies separating users that won’t feel degradation as much with users that are very sensitive to it (agents and power users vs users doing simple tasks). Limitations: The visualization and paper examples are a toy example to illustrate the problem, only the providers have enough data to properly calibrate these instances. In the paper there are some interesting calibrated instances. Technical Details: The visualization is around 100 lines of flask plus js frontend (LLM assisted with ground truth based on the original numerical example of the paper). Paper with proofs/theory: https://arxiv.org/abs/2608.23986
OzBrain, a shared brain for knowledge between agents and your team
I think agent-first chat interfaces will be a primary software modality and busy dashboard/UI will go away. I’m not sure who exactly wins it, but I want my knowledge to grow/go with me. A lot of the “knowledge” ie research, analysis, reasoning will be done by agents as the primary user. Our current notes tools & tasks management systems were built for humans… I don’t care what the 17th thing on my bug backlog is. I want to conduct agents that can execute for me and do great work. What I built OzBrain to do: + Create a central place for agent reasoned knowledge to live + Be agnostic about what apps/agents connect to it + Capture everything and track it so I can audit it + Enable teams, collaborators or partners to share brains + Handle conflicts so many agents in the same article doesn’t blow up + Refactor knowledge into more token friendly chunks and map the index well + Close the knowledge loop so new thinking supersedes old thinking across the corpus. Don’t erase, depreciate and link + Keep user data safe and secure ++ Be easy enough to use that you don’t have to have any technical knowledge Some among us will always build their own custom solutions, but there are millions of tech professionals and small business owners that will use agents heavily and need a solution. So I’m trying to build that. Isn’t this like gBrain? Yes, similar. I think it’s like AWS vs Vercel. AWS is very powerful, configurable, and useful if you’re technical and want to invest the time into really fine tuning your system… but if you just want your web deploy/hosting to just work and be easy to deal with you use Vercel. // WHY I MADE IT I’ve been enjoying getting back to my technical roots, as I lost my coding skills more than a decade ago, but with AI I can focus on the system and the product in partnership with agent coding workflows. I recently built a Voice AI for older people. To build it I created an agentic engineering workflow (feel free to rip that up as I’m always looking to improve systems: https://ozbrain.com/resources/eng-flow) My approach with coding agents is trust but verify, and I’m trying to replace the parts where a human would review with an adversarial or specialized agent who would give a better answer/review. I have workflows that will go high level task to shipped PR running in Claude cloud sessions. I use Claude Code locally and Cursor when I want a tighter loop on doing visual work like UI or layout. And Codex to either load balance usage for TokenThriffting or when I want a different llm to think thru something. It was a pain in the ass passing .md files around and keep track of which version was the most recent, so I built a hosted .md storage right in Supabase and any of my agents already have Supabase access. This let me build a solid, scalable, secure voice AI from my phone at the gym. All my agents have access to our knowledge, can write to it, update and refer to it as we build and improve the product and the systems we use. Out of 75 founder friends I asked about how they manage shared knowledge, 26 built their own custom knowledge systems… Obsidian vaults with 7k files synced through a VPS, markdown repos behind their own MCP servers, cron jobs stitching Supabase to a skills file… each a different Frankenstein they have to maintain. 32 said they felt the pain of moving static files around but didn’t have any solution for it. So I rebuilt my brain better and used it to build it. // HOW YOU CAN HELP Would love to have you try it out. The maintenance loop is still in alpha so not running it on customer data yet. If you built your own brain I’d love to hear how you did it. What criteria was most important for you in its design & function. If you are tired of shuffling .md files around I’d love to have you try out OzBrain and to give feedback, just ask your agent to put it in the shared bugs & features brain! Cheers! Bubs.co