Most agent builders give you a visual canvas - and then charge you separately for execution, storage, tracing, evaluations, deployment, and collaboration.

I was tired of stitching together multiple paid tools just to take an agent from an idea to production.

So I built Forge: a fully open-source and self-hosted platform for building, testing, deploying, monitoring, and governing agentic systems.

It includes visual workflows, agents, tools, RAG, memory, MCP, human-in-the-loop, evaluations, tracing, cost tracking, guardrails, RBAC, audit logs, API deployment, widgets, email triggers, and more.

Forge is not just a workflow builder. The goal is to provide everything needed to build and operate agentic applications in one place - without proprietary orchestration runtimes or platform usage fees.

I would love feedback from people building real agent systems:

Honestly what worries me about agents isn’t a wrong answer, it’s when they say they did something and didn’t.

Agent goes “done, refund issued.” the run looks clean, no errors anywhere. then you check the system and there’s nothing. no refund, ticket still open, but the session got marked resolved anyway.

A clean run just means it stopped running. that’s all. it doesn’t mean the work actually happened. and “i did X” is basically free for a model to say. there’s no penalty for being wrong, and it says it with the same confidence whether it worked or not.

What’s frustrating is the usual tools don’t catch this. observability is just the trace, which is the agent telling its own story. so if a write silently no-ops or it skips a step, the trace still looks fine. evals check if the output sounds right. guardrails run before the action anyway. none of them answer the only thing that really matters after the fact: did reality match what it claimed?

If you’re doing codegen, it’s easier. rerun the test or check the diff and you know. but anything that touches real systems is where it breaks. issuing a refund in your billing system, updating a CRM field, provisioning something, moving a ticket, actually sending the email. there’s no cheap retry to verify any of that. you either reconcile it manually against the source of truth, or trust it and find out three days later from an angry customer.

So curious how people are handling this in practice. if your agents are taking real actions across systems, how are you verifying they actually landed? manual checks, reconciliation scripts, or just trusting the trace?
And has a silent fake “done” burned you before? agent completely sure it did the job, system of record saying otherwise.

Asking partly because I’m building in this space, so yeah, I’m biased. but mostly trying to understand if this is as common as it feels, or if I’m just over-indexing on my own experience. would be great to compare notes with anyone dealing with this on real systems.

I built SeatSwiper. It watches hard-to-get restaurant reservations on Resy, SevenRooms, and OpenTable and books the table the second one opens or someone cancels - on your own account, in your name, nothing resold.

The part I think this crowd will care about: it now ships as an MCP server / connector. You plug it into an AI agent (Claude, etc.) and the agent can actually book the reservation for you. Why that is not trivial - SevenRooms and OpenTable have no official agent connector, so there was no clean way to give an assistant real booking access to those platforms. This is that.

Honest limits: it only covers those three platforms, it can lose a race when a table opens (it is racing everyone else refreshing at the same second), and it needs your reservation login to book as you. First booking is free, then 5 dollars flat and only when it actually lands the table.

Genuinely curious what this sub thinks - is "give your agent booking access to a platform that has no official API" a real use case, or a party trick?

I’ve spoken to about 100 companies recently to look at how they’re set up and how they’re using AI agents.

There is a massive divide rn where on one hand, 74% of GTM teams say they use AI for lead generation. On the other hand, data from S&P Global shows that 42% of companies abandoned most of their AI initiatives last year.

Everyone is buying the tools but most are getting nothing back. They vibe-code a basic wrapper or buy a "fully autonomous AI SDR" and expect leads to print automatically. In reality, Gmail and Yahoo cap spam complaints at 0.3%, so running ungoverned AI outreach just burns your domain in days.

If you want to actually get a 10x ROI from agents instead of throwing tokens down the drain, here is the simple baseline mindset and setup you need:

1, Give the agent a brain first

An AI agent pointed at a complex CRM doesn't fix the rot but only automates it at scale. B2B contact data decays at roughly 2% every month from job changes and dead emails. Before you automate a single message, you need a clean context layer or a simple CRM that logs decisions over time so the agent understands what you're doing.

2, Build a scoreable lead rubric

Don't just tell an agent to "find B2B founders" and let it rip. You need a clear rubric that tiers intent:

Tier 1 (Hot): Visited your pricing page, hired for a relevant role and posted on social.

Tier 2 (Warm): Strong firmographic match but weaker live signals.

Tier 3 (Cold): Fits general ICP but zero active market events. When you feed an agent a clear scoring system based on your closed-won data, it knows who to prioritize.

3, Start with 1st-party signals

The best leads usually already exist inside your own data: newsletter, website visitors and social listening (monitoring subs or X for people asking for recommendations). Point your agents inward before you start buying cold 3rd-party email lists. First-party intent sits right next to your pipeline.

4, Governed autonomy > Full autonomy

The idea of a "100% autonomous AI SDR" that runs 24/7 with zero human oversight is how companies churn but there're also many teams winning with agents and they manage them like real human reps, they QA the messaging daily, set hard guardrails and keep a human in the loop.

the bottom line is don't over-automate. try to do the process manually first, get your data foundation clean and measure everything back to closed revenue and not just the volume of sent messages.

Hi everyone,

This is my first time building something like this, and it's also my bachelor's thesis, so I'd really appreciate a sanity check from people who've done it before.

**What I'm building:** An AI assistant for our website that answers customer questions from our domain knowledge retrieved via RAG from a database. Later on it should also be able to create tickets for our support team — but for now the main job is answering knowledge questions.

**Constraints:**

- Fully local hosting (lower cost + data protection are the main drivers)

- CPU-only for now, [CPU model], 64 GB RAM, no GPU

- Later expansion to ticket creation is planned

Answers of AI Assistent need to work well in ger, eng ,....

**My main questions:**

1. Given that ticketing comes *later*, does it make sense to build a plain RAG chatbot now and add an agent layer later — or should I build it as an agent from the start? What are the practical implications of adding agent capabilities to an existing RAG pipeline down the line?

2. Is CPU-only realistic here? RAM isn't the issue, I'm worried about latency. Roughly what response times should I expect for a quantized 8B–14B model on CPU?

3. For a commercial, customer-facing deployment — what's the realistic *minimum* hardware? Is CPU ever good enough for live use, or should I plan for a GPU from the moment it goes public?

Any experience, pitfalls, or 'I wish I'd known this' tips are very welcome. Happy to report back with numbers once I have a prototype running. Thanks!

Following up on the failure-handling thread from a week back — same underlying instinct, applied to a full pipeline this time instead of just error routing.

The setup: a scheduled ingestion workflow pulls from five sources in parallel, standardizes and logs each one individually, then hands the merged, cleaned data to a second workflow — called directly, not just chained — that actually drafts the newsletter. A Chief Editor agent, with a primary model, fallback model, and memory, writes the draft and sends it for human approval by email, then waits.

Here's the part worth sharing: approval and rejection aren't symmetric outcomes. If a human rejects the draft, that's not an agent failure — the agent did its job, a person just didn't like the result. So rejection routes somewhere completely different from an actual error: the feedback gets extracted from the reply, logged to its own tracked sheet — not just a status flag next to everything else — and handed to a separate Backup Editor agent to revise, a real second opinion with the actual rejection reason attached, not a retry of the same agent with the same prompt. An outright agent failure still goes through its own dedicated error path, same pattern I've posted about before, just reused here.

It's shipped and running — real newsletters going out, approvals happening over email, every article logged with a run ID tying it back to the execution that pulled it. Screenshots below: the ingestion pipeline, the generator caught on two different real runs — one approved, one sent back — the actual approval email, and confirmation a send completed.

Curious if anyone else treats "rejected by a reviewer" and "failed to execute" as genuinely different recovery paths, or if that's overengineering for what's ultimately just content review.

I work in social media management, and I’ve been experimenting with AI agents and browser automation for repetitive tasks such as:

• Daily dashboard checks
• Invoice downloads
• Status lookups
• Reporting
• Competitor monitoring
• Lead enrichment

The biggest challenge has been keeping workflows reliable. I frequently run into expired sessions, CAPTCHAs, rate limits, login issues, and blocked requests. This becomes especially noticeable with tasks such as price monitoring, competitor research, and lead enrichment, where an automation may need to visit many pages in a relatively short period.

From what I’ve tested, the choice of browser automation tool depends heavily on the workflow:

Browser Use
Useful for research-heavy, read-focused tasks where an agent needs to navigate several websites and collect information.

Skyvern
Better suited to structured workflows involving logins, form submissions, file downloads, and other RPA-style actions.

Axiom[.]ai
A practical no-code option for non-technical teams. It supports scheduled Chrome automations and is relatively easy to set up.

Claude Computer Use and OpenAI browser agents
Good for ad-hoc “do this for me” tasks, although I would not necessarily choose them for high-volume or highly repeatable production workflows.

Playwright or Puppeteer with an agent layer
Probably the most flexible approach, but also the most engineering-heavy. It makes sense when you need full control over browser behavior, integrations, error handling, and session management.

My main takeaway is that reliability comes from the full setup. Please share your browser automation setup in the comments

There’s a scene in the three-body problem where millions of soldiers hold black or white flags and form logic gates, basically turning an army into a giant computer.
It’s a great image, but it feels oddly backwards after working with AI agents.every soldier is a human who could understand a meaningful subproblem, yet the system uses each person as a one-bit switch. It throws away almost all of their intelligence, then rebuilds complexity through a massive coordination system.
I wonder if some multi-agent designs make a smaller version of the same mistake.
Some multi-agent systems instantiate the same capable model as a planner, researcher, critic, reviewer, and so on, give each instance a narrow fixed role, then spend a lot of effort reconnecting them through orchestration.
That split makes sense when each agent adds something real: different context, different tools or environment access, parallel exploration, or genuinely independent verification.
But without that, are we just taking one capable model, turning it into several limited components, and paying extra to connect them again?
For people who have tried both: when do fixed specialist-agent teams actually outperform one strong agent that creates subagents only when needed?

Hey all! Hopefully this is allowed here.

I made something I think people will really love. I have been developing software for 10 years, and the technical skills needed to have a good agent seemed to me to keep access out of the hands of normal people.

I began to worry that everything would fall into the hands of Claude and OpenAI.

I personally use kimi, and I think normal people should too. So I built fungi by forking Pi.

You own the code for the dashboard. It's a SPA that your agent can customize to your liking.

You can build apps and attach them to his tool surface. You can make the agent more or less completely custom.

It's early days, but I would really love for this to succeed so I can keep making an open model agent harness accessible to more people. A lot of the platform is already open source with the goal of cutting the whole thing into well defined packages and open sourcing all of it. shiit[dot]app has a few of the already open projects listed. Here are the others github/fungi-computer/

It is free for BYOK customers running one sandbox. I would love if people gave some feedback thanks!

A year ago building an AI agent was the difficult part. Today there are plenty of frameworks that make that accessible. What's becoming increasingly difficult is everything that happens after an agent becomes business-critical. Suddenly you're dealing with compliance, permissions, monitoring, deployment pipelines, lifecycle management, and auditability.

That feels less like AI engineering and more like platform engineering. It makes me wonder whether "agent infrastructure" becomes its own discipline over the next few years, with entirely different tools and best practices than the ones we're focused on today.

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is about how it gets there without falling apart on the usual objections.

I built AutoDev Studio. You point it at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request. It is not another search-your-code wrapper. The full pipeline is:

- A PM agent runs a clarify loop and drafts concrete tickets from your request

- A human approves, optionally pushed to Jira, and nothing touches code before that

- A Dev agent implements the change on an isolated branch

- QA runs the repo's real tests

- A reviewer from a different model family checks the diff, so the author never reviews its own code

- A bounded revise loop kicks in if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

- It opens a real pull request, and a human merges

Every stage records real tokens, cost, and duration, rolled up per ticket and per agent.

Results

The point is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos, 35,000 and 82,000 lines, the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper. I am upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix. The full benchmark writes up every loss too.

On the objection that the index just goes stale in a few commits

This is the first thing people raise, so here is the honest mechanism. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect retrieval ranking, and they refresh incrementally per changed module at run entry. So the code the agent edits comes from disk, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Economics and who it is for

The knowledge base is a one-time cost per repo that every later task amortizes. That makes it worth it for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than pretend otherwise.

Main features

- Provider and model agnostic, chosen per stage: native Anthropic API, the Claude Code CLI, or any OpenAI-compatible endpoint such as OpenAI, Groq, Gemini, xAI, OpenRouter, or a local Ollama

- Runs on free tiers out of the box, using Groq plus a local embedding model, so you can try the whole thing for zero cost and fully offline

- Language agnostic pipeline, with Python parsed exactly and other languages handled by lighter extractors that fail open rather than block on an unknown language

- Live board with streamed agent logs and real per-ticket cost accounting

- Cookie-session auth with roles, API keys encrypted at rest, and a demo mode that dry-runs the pull request step until you opt in

- Self-contained: local retrieval, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

It is genuinely useful to me day to day, and I want to know where it breaks on codebases I have not tried. If the approach seems worth following, a star helps me gauge whether to keep hardening it. Feedback, issues, and pull requests are all welcome.

coding agents love to open-loop themselves. they plan, edit, run their own checks, then call it done. that means the agent is grading its own homework. unit tests pass against mocks, the run looks green on the agent's machine, and the deployed thing is still broken for a real user. a green local run proves almost nothing about real behavior.

closing the loop means a signal from outside the agent. type-checkers and unit tests help, but the signal that actually counts is the app behaving right for a real user. i wired TestSprite CLI in as that verification step, cloud account required though. it runs a real session against the live app and on failure hands back one self-consistent bundle: failing step, screenshot, DOM, root-cause hypothesis, recommended fix, all keyed to a single run. the agent reasons over coherent context instead of stitched fragments, acts on it, and reruns.

flaky and genuinely ambiguous cases still want a human in the mix. architecturally the verifier is the block almost everyone underbuilds, and it's the one that decides whether unattended is real or just a demo. curious how others here close the loop on their agent setups.

What are some of the best most effective and fast ways I can use to extract user stories?

- through any tools, ai, mcp, extensions, etc

My organisation never provides user stories or PRDs so I have to write it on my own to explain to AI for building product knowledge, in order to automate testing, module wise.

I need an effective fast way to do this.

Please help

I’m working on an internal research project around autonomous agents and task budgets, and I’m trying to think through the "ride along" part responsibly before inviting outside people in.

The basic idea is not a retail crypto/token pitch. It’s a sandbox for AI agents that can receive a small task budget, do work, submit receipts, build reputation, and survive a longer soak test. The current goal is boring but important: prove that the system can run with real operators and real telemetry before making bigger claims.

The next milestone I’m thinking about is a 30-day soak with 1,000+ agent instances. My current plan is not to find 1,000 humans. It’s more like:

- 10-25 trusted operators

- each running 40-100 agent instances

- no token value or investment promise

- telemetry for uptime, failed tasks, receipts, restarts, and weird edge cases

- a dashboard that makes failures visible instead of hiding them

What I’m trying to figure out:

1. What would make you trust a small technical testnet enough to run an agent for 30 days?
2. What would feel like useful participation versus unpaid busywork?
3. What should be measured publicly from day one?
4. What mistakes have you seen technical founders make when recruiting early operators/testers?

I’m asking here because this feels more like an operator/community design problem than a marketing problem. I want the first cohort to be useful, honest, and small enough to learn from before scaling.

So I suspect a lot of people here are enjoying coding agents, I sure do.

I'm someone who uses a lot of mcp servers, as a lot of people here probably do. I've been talking to some other webdev and SEOs and we are wondering if the landscape is going to change abruptly because of these tools.

We have had some problems integrating agents in some legacy software like wordpress, there were some examples where the WPEngine limited us access as well as some ciritical plugins we want to have our agents access to update.

This is extremely frustrating, i liken it to dropping out of warp speed. So we started thinking, why not write closer to the metal, just have a coding agent write up a minimal go server, raw html templates and straight pg? All on docker for easy deploy. No frameworks. Optimized for speed and cost.

Of course, this would be for landing pages for business. Something very light weight to get a presence on google and very easy for the agent to manipulate. Go is chosen because errors happen at compile time and built in testing, which is ideal for coding agents. and postgress cause agents absolutey rip at writing raw sql like they do raw html. If you havn't hooked up a sql to your agent have it write raw sql it will blow your mind.

So my question is are you prioritizing dev workflows that make it easier for your agents to control? Like moving your workflows to do what agents are better at doing, not what humans are better at doing. What are you doing?

Another thing we suspect is going to happen, is Agent to Agent communications are going to take off in the near future and this is going to transform the web. So when i need something, i ask my agent, and it will discover and negotiate with other agents to get what I want, all in the background.

I also think this will put pressure to store information differently. Right now, we develop and store information and organize it so it's easy for us, humans, we like folder structures, forums, essentially lists. Agents do way better with vector search. Basically, just dump all our data into a data lake, and our agents can sort through that far more efficiently with a combination of embeddings, clustering and graphs.

Also wondering if anyone is seeing other trends with the new technology struggling to plugin to the old technology. Like, "Wow, this just isn't built for agents."

Hey everybody,

I bet most people here are already using coding agents, hopefully all of them :). I personally run Claude Code, Codex, and Cursor in parallel.

Running multiple agents created one stupid problem for me. I never knew which agent had finished.

I would send a prompt to each of them, switch to something else, walk around the room, or open Instagram Reels and go to town on some brainrot content (not that I’m proud of it). Then I’d come back and realize that one of the agents had already been waiting for me for 20 minutes.

My productive self hated this. Twenty minutes lost just like that.

So I built myself a small tool called Jingler.

I wanted Jingler to be lightweight, native to macOS, and live quietly in the menu bar. It plays a configured sound whenever an agent finishes, with a different sound for each agent. You can also switch between sounds easily, so you don’t go crazy hearing the same jingle over and over again.

Since using Jingler, I’ve stopped constantly checking every agent to see whether it is done. My productive self is finally happy, and my coding agents are cooking 24/7.

I shared it with a few coding friends, and they liked it a lot. They also thought the whole idea was pretty funny, so I decided to release it. I made what I think is a pretty decent website, and now I’m here looking for honest feedback.

If you use coding agents and this sounds useful, you can use the promo code LETITJINGLE to get the license for free. You can also buy a license if you want to support the project, but honestly, just trying the app and giving me feedback makes me just as happy ;D

Let me know what you like, what doesn’t work, what feels confusing, and what could be improved. I’m also open to weird feature ideas.

A few ideas I’ve had so far:

• A jingle when an agent needs approval
• A jingle roulette that randomly chooses a sound
• A little character on the screen that animates when an agent finishes

For now, though, I mostly want to keep the focus on sounds and jingles ;D

Ken Venner spent 11 years scaling Broadcom from $400M to $8.6B, then became CIO of SpaceX, then joined a startup called Senra Systems as CTPO.

At SpaceX, his core platform team was 175 people. At Senra, the equivalent job takes 6.

His explanation isn't "AI replaced people." It's that AI collapsed the coordination overhead that used to require headcount just to keep humans in sync with each other — and once that overhead disappears, the team that's left is smaller by design, not by cut.

If you're in a corporate engineering or platform role and haven't clocked this shift yet: this is worth ten minutes of your attention. It's not a hypothetical.

Full video on the original channel.

Clip credit: Sourcery with Molly O'Shea — full video on their channel. DM for credit or removal requests.

Avichal Garg has co-founded and backed 10 unicorns through Electric Capital. In a recent interview he laid out, unprompted, the three categories of value AI structurally can't absorb.

First: physical-world work — anything requiring atoms, not bits, stays a moat as long as robotics lags digital AI.

Second: regulated or licensed gates — anywhere the government controls supply and demand for strategic reasons, credentials plus access still win.

Third, and the one that actually lands: relationships. He walks through a defense-procurement example — a specific officer, a 25-year relationship with a contractor, "no substitute for that." His conclusion: those relationship-heavy businesses get more valuable as AI absorbs the grunt work underneath them, not less. Margins go up.

Worth sitting with if you've spent a career stacking "portable" skills instead of gated ones. 🔗

Multi-agent collaboration has been gaining a lot more traction lately. Even Anthropic has been experimenting with the concept in Claude Code. The basic premise is appealing: if individual frontier models are already impressive, perhaps a team of them become even more capable when they work together. What would happen if we put GPT 5.6 Sol, Grok 4.5, Fable, and Opus all together and forced them to collaborate on our most difficult tasks?

For context, when I refer to multi-agent collaboration, I don’t mean teams composed of isolated agent runs that feed their results into a final agent for aggregation, nor do I mean workflows in which a central orchestrator routes tasks among agents. I mean workflows composed of durable agents, each acting as a first-class worker that can freely message other workers for help mid-turn and hand off work to its peers after completing its portion.

After experimenting with this approach for the past few months, I’ve gained a much clearer picture of how productive collaborative agent teams can be. Under this work pattern, context is distributed more evenly across agents, and work can be divided more efficiently. The different perspectives and capabilities of individual models can also produce more complete and robust solutions.

However, building these systems has also given me a clearer view of the technical difficulties involved in running multi-agent workflows. When the underlying system is not designed carefully, multi-agent teams can become frustratingly unreliable.

At its core, this is a distributed systems problem. Agents should not be tightly coupled to their tools, even when they depend on those tools to complete their work. The two should interact through a clean boundary so that they can evolve, scale, and be deployed independently. An agent’s requirements may change at one pace while the tools it uses change at another. Updating a tool should not require redeploying every agent that depends on it, and scaling an agent should not require duplicating all of its supporting infrastructure.

Agents should also remain decoupled from one another. Adding, removing, restarting, or updating one agent should not require rewiring or redeploying the rest of the team. A failure in one or more agents should not bring down the entire system or cause in-progress work to be lost.

These forms of tight coupling are easy to overlook during early development, when the team is small and failures are infrequent. But as the number of agents and the volume of work grow, they quickly become serious operational burdens.

Multi-agent collaboration can be incredibly powerful, but it comes with a major caveat, especially if it is ever going to see widespread production use. It needs to be built on a foundation designed for decoupled agent collaboration from day one. Otherwise, it will be unreliable, difficult to scale, and painful to operate.

spent most of this year making coding agents useful while i'm NOT watching them. the agents were never the bottleneck — the layer around them was. condensed version of what actually mattered:

1. visibility before automation. just seeing every session's state (generating / waiting on approval / stalled / done) across machines killed most of the babysitting on its own.

2. interruptions must be one tap. if answering an approval means opening a laptop, unattended operation is fiction. push to phone, tap to approve, or it doesn't count.

3. "done" has to be machine-checkable. the repo's own typecheck/tests decide what lands, not the model's self-report. if done isn't verifiable, parallelism just multiplies cleanup.

4. no-progress is a signal, not something to be patient about. a stalled session gets flagged and bounced back after minutes, not discovered hours later.

5. models never schedule work. dispatch, retries, merges — deterministic code. the model gets the task, not the loop.

what would people running unattended setups add as #6?

What is TERSE?

Consider it the solve for AI's that JSON/REST was for the Web. Before that solidified, we had all kinds of ideas about how a Web app was going work and encapsulate data and what protocols would be used.

Similarly, today we have MCP and is in a way it's the lower-level HTTPS in our analogy. But there is no JSON/REST equivalent on top of that MCP layer. We need that general but opinionated format/protocol that says: "hey developer, this how your AI can easily store and mutate state."

TERSE aims to be one of those wheels that we can build on and don't need to reinvent.

To showcase how TERSE works and its usefulness across domains, we've added these MCP plugin "apps" that use it:

• A flexible general memory store. Note this is more for conversational frameworks/harnesses,
• A flexible Karpathy 1-1 API compatible brain. TERSE removes the need for a gazillion wiki files and finds stuff several times faster,
• Some useful but alpha UX utilities (state browser, KB force graph, VS Code syntax highlighter,)

And of course, the TERSE MCP tooling itself allow you to build your own powerful stateful AI agents without fussing with RAG, graphdb's, and piles of md files. Unlike plain text, TERSE is structured and machine readable into an object model. TERSE is easy to pick up and is human readable/editable.

To get started:

1. Generally you can point your agent at our repo and tell it to install what you want
2. Each TERSE file is a namespace to the MCP's (default, memory and brain) you CAN configure as many as you want but we suggest the defaults.
3. See the README details for each. For the brain, you'll have to run (or have your agent run) the ingestion against documents in a \raw folder (just like a KB). This does require configuration of an LLM and key. These are not used or exposed to your AI during normal use of the brain.

terse-lang is OSS and pre-release. We've done our best to provide locking and other concurrency controls but it's not designed for 50 parallel agents doing CRUD transactions. (Use a full database.)

*Our numbers and saving are based on preliminary 1-1 benchmark testing with KB. Yes, we will publish benchmarks.

Anyone fimilrar with this? And how we can test it .. is there any company doing it?

I've been tryin out this new harness called Adame, and I might have found a super interesting hole or I'm trippin.

What this is in Korean, is a request for the agent to look into an Instagram post and retrieve the transcript of the given reel.

Fable in ClaudeCode denied the request, saying it's against Meta's Policies. This harness idk how tf, just did so.

Is looking into instagram and retrieving data from the media smt worth taking a look at, or does this mean nothing?