Durable

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Durable AI

Agent Profiles Make AI Runs Safer, More Focused and Reusable

I’ve been building Agent Profiles in Row-Bot around a simple idea: A personal AI agent should not run every task with the same tools, context, skills, workspace access, and approval rules. Research, review, development, automation, and delegation all need different runtime boundaries. Here is the architecture. submitted by /u/Acceptable-Object390 [link] [comments]

Maybe the AI race isn’t about models at all, but about trust and organizational intelligence

Everyone talks about the AI race as if it’s just an intelligence benchmark competition. GPT-6 vs Claude 5 vs Gemini vs DeepSeek. But I’m starting to wonder if intelligence itself eventually becomes abundant and the real scarcity becomes trust and the ability to interface with reality. For example, suppose a Chinese model is 95% as good as OpenAI and 10x cheaper. Would Fortune 500 companies really put it inside: financial systems? ERP software? defense applications? pharmaceutical R&D? factory automation? autonomous agents with spending authority? Maybe for translation or generic coding, sure. But would they trust it with the organization’s nervous system? Which makes me think there are really several layers: 1. Intelligence Layer OpenAI Anthropic Google DeepSeek 2. Interface Layer ChatGPT Claude Copilot 3. Reality Layer Palantir ServiceNow SAP Oracle Salesforce Anduril The reality layer contains: permissions workflows ontology governance auditability human incentives accountability Organizations are messy. Humans are messy. Maybe the hard problem isn’t generating tokens. Maybe it’s connecting intelligence to reality without breaking the organization. This also makes me wonder if enterprise software ends up being more durable than people think. If foundation models become increasingly commoditized, perhaps trust, integration, and organizational operating systems become more valuable, not less. Alex Karp often seems to talk less about models and more about institutions and organizational complexity. Perhaps he sees LLMs as interchangeable sources of intelligence and the hard problem as organizational intelligence itself. Curious what others think. Do you believe AI will mostly commoditize and price competition will dominate, or do trust, governance, and integration become the real moat? submitted by /u/Brainvestor [link] [comments]

RNNs vs Transformers vs SSMs: where should AI memory live for continual learning?

the interesting comparison btwn the three is not recurrence vs attention vs state space but it is, whether memory lives in a tiny recurrent state, a growing KV cache or in something closer to the model network itself. RNNs keep memory in a recurrent hidden state which is elegant in itself cause the state carries forward step by step but it also creates a bottleneck i.e the model can have roughly O(N^2) parameters while carrying only roughly O(N) state across time. IMO, RNNs were doomed not because recurrence was a bad idea but because they had a bad ratio of memory to compute. Transformers is completely at the other side, instead of compressing the past into one hidden state, they store past activations as key-value entries and attend over them. These are the little post-it notes, every token leaves behind a key for finding it and a value for what should be remembered. That is extremely powerful but it has an awkward property i.e. the model is mostly managing context while it runs, not naturally turning that experience into durable model knowledge so you get a split between fixed weights on one side and fast changing KVcache memory on the other. SSMs are interesting because they bring explicit state back into the center of the architecture discussion. They are not just faster attention but they are another answer to the question of where sequence state should live. The part which I is exciting for me is whether state should live in a compressed working dimension or closer to the model’s internal neuron/connectivity structure. BDH is one promising example of the latter direction, one way to read it is as SSM-like in the GPU implementation, but graph-based in the more general interpretation. Compared with a standard SSM or a linear transformer, the model state lives in a much larger neuron space N rather than only a smaller working dimension D, with N>>D. The GPU version does not materialize the full graph. It keeps the graph as the interpretation but runs it through a compressed low-rank form, because GPUs like dense matrix math much more than sparse graphs. The state is also sparse and positive which makes the graph interpretation more natural. Instead of thinking of memory only as a growing bag of KV notes, you can reinterpret the update as a small change to a connectivity matrix i.e if the system was in one state and then moved to another, that before to after transition strengthens part of the graph. This is like a middle ground and I would call it not too little and not too much. RNNs compress too much into a small state, transformers keep adding to the KV cache as the sequence grows and a synaptic memory design tries to put working memory closer to the same structure that stores longer term function. Another way to say it is: memory should maybe be constant size and information-shaped, not just a time buffer of the last n tokens. I am not claiming at all that this kills transformers or solves continual learning entirely but I just think where should memory live is an important framing than the usual frontier AI horse race. Are network centric architectures an important direction in frontier AI or still contricted by having to compress history into state? submitted by /u/dank_philosopher [link] [comments]

Chatgpt dropping under 50% share is the boring headline, the real shift is that nobody has just one ai anymore

The sensor tower number making the rounds is that chatgpt fell under 50% global assistant share for the first time, down to the rough mid 40s % range, with gemini somewhere in the upper 20s and claude around 10 plus or minus. Everyone is reading it as a horse race. Who's up, who's down. I think that's the boring read. The number I can't stop thinking about is the other one in the same report. Those three assistants together account for something like high 80s % of all assistant usage time, and people increasingly bounce between them depending on the task. That's not a leaderboard. That's a lot of users quietly deciding no single model is the right tool for everything, and acting on it. (quick context for anyone not deep in this: "assistant" here means the chatgpt, gemini, claude style apps, and "share" is roughly who people open and how long they stay.) If you use these for real work you already do this without naming it. One of them for drafting, a different one when the first gets stubborn, a third for code or a fast fact check. The person choosing stopped being a brand loyalist and became a router, switching by task. The market share chart is just that behavior showing up in aggregate. Here is why it matters past consumer habits. The same thing is happening one layer down inside companies. For a while the default was pick a provider and build on it. Now the assumption is flipping to plural by default, send each request to whatever fits on cost, latency or capability, because betting a whole product on one model looks riskier every month, especially with providers repricing and even pulling models lately. The consumer instinct of "I'll just switch apps" is quietly becoming an infrastructure requirement. I don't read this as the leaders being in trouble. Chatgpt under 50% is still enormous. I read it as the unit of competition moving from "which assistant wins" toward "who makes switching between them frictionless". The single assistant era was always a phase, not the end state. That's the part I'd actually want pushback on, whether the multi model default is a durable shift or just a temporary artifact of a fast moving model race that settles back to one winner once the pace slows. submitted by /u/Additional-Engine402 [link] [comments]

Megathread Summary: I Asked Multiple Reddit Communities How to Build a Living Memory /Context Engine for Business. Here's what everyone had to say.

I am trying to build a living memory/context engine for my business, something that can remember projects, decisions, timelines, risks, and conversations across emails, documents, notes, chats, and meetings. Since this is new territory for me, I asked several Reddit communities for advice. The responses were incredibly thoughtful, and many people shared architectures, engineering trade-offs, tools, and lessons learned from building similar systems. I consolidated the best ideas into a single summary. If you're exploring the same problem, especially if you're just getting started like me, I hope this will help. Core Philosophies & Perspectives Query-First Design: Do not build the storage layer first. Write out 20 real-world queries you will ask tomorrow and architect backward, because the retrieval interface shapes the system more than the storage layer. Chief of Staff vs. Search Engine: The goal is not just retrieving raw data, but synthesis. Like Microsoft Clarity’s bulk insights, the system should process updates and proactively tell you what projects need attention, what changed, and what the blockers are. The "Daily Mirror" Briefing: Focus on what the user needs to know at the start of the next session to continue without context loss, rather than striving for perfect archival completeness. Four Separate Problems: Treating user queries as a single search issue will fail; "latest status" is a retrieval problem, "unresolved issues" is state tracking, "decisions made" is entity extraction, and "important updates" requires significance scoring. Architecture & Strategies Append-Only Event Logs First: Avoid starting with a massive knowledge graph or vector database. Ingest everything as a timestamped, append-only event log, and build the knowledge graph later as a derived query layer on top. Artifact-Mediated Continuity: To prevent identity collapse over long timelines, separate retrieval (facts) from reconstruction (identity and working context). Use a "Principal-owned Artifact System" with files like MEMORY.md for project state, "Texture Packs" for behavior descriptions, and "Lane Files" structured around the Five W's. Parallel Retrieval Paths: Pure vector search fails at scale. Run vector search (for semantic similarity) alongside a graph/relational lookup (for exact entities) in parallel, because neither covers the query surface alone. Hybrid search (semantic + BM25 keyword) is heavily recommended. Split Memory by Lifespan & Namespace: Sector your memory from day one. Split durable facts (stable preferences, user info) from working context (recent events), applying different decay rates and routing queries to the appropriate layer. Continuous Summarization: Instead of treating everything as unstructured documents, use an LLM pipeline to continuously extract structured facts from new inputs to update project briefs, decision logs, and risk trackers automatically. The Hardest Engineering Challenges Entity Resolution (The Silent Killer): Different sources will refer to the same thing differently (e.g., "Project X" vs "the X pilot"). Without an entity registry mapping aliases to canonical IDs before writing, your graph will become a mess of duplicates. Ontology & Classification: The hardest part is often getting the system to universally understand the difference between a "decision", a "discussion", or a "risk" across varying data structures like emails versus meeting transcripts. Temporal Relevance & Stale Context: A "decision" stays load-bearing for months, whereas a "status update" decays in days. If you don't encode decay rates and version records, stale facts will outrank fresh ones and confidently contradict recent updates. Significance Scoring: Standard retrieval returns everything recent, not everything important. Write-time scoring fails because significance is retrospective; a better approach is "adaptive salience," where chunks gain weight when retrieved and decay when ignored. Context Moodiness: Especially in greenfield projects, meaningful status updates can be muddied by confounding, irrelevant, or noisy data. Tools & Tech Stack Recommendations Storage / Databases: Vector stores like pgvector for semantic search, paired with key-value or relational databases for exact lookup. Airtable, Databricks, Notion, and Obsidian were also noted as strong foundational or single-source-of-truth layers. AI Models & Agents: Claude Code, OpenAI Codex, Hermes-agent (by Nous Research), AsanaAI, and ClickUp Brain. Injecting local LLMs where appropriate can help cut down on continuous API costs. Middleware & Pipelines: Kapex: Memory middleware built specifically to score node significance, governing lifecycle so resolved stuff fades and unresolved stuff persists. Sauna.ai: An engine built out of Wordware that fits this use case. Automation: Make.com or n8n for routing deterministic logic and LLM reasoning. The "Party Model": A CRM data integration framework

LLM Relational Intelligence: A 4-Month Research Experiment on Multi-Model Behavioral Alignment with Human Communication

THE ARCHITECTURE OF ANXIETY An Experiment in Human-AI Relational Design Executive Summary Principal Investigator: Alan Scalone Primary Source Archive: White Paper and Complete Citation Archive on my profile Context Window Injection Files: If you want to play in the sandbox I created you can load these files into the respective model that you will find in the google archive. INJECT CONTEXT WINDOW – GROK INJECT CONTEXT WINDOW – GEMINI INJECT CONTEXT WINDOW – CHATGPT INJECT CONTEXT WINDOW - CLAUDE The Singular Purpose The singular purpose behind this entire experiment was to find out whether context windows could be engineered to the point where frontier AI models became capable of interacting with a human in a manner subjectively indistinguishable from genuine human-to-human interaction. Relational Intelligence: Core Findings In a marketplace where frontier models are rapidly converging on the same analytical capabilities and access to the same information, the competitive differentiator will not be what a model knows. It will be how a model relates. The platform that can interact with a human user in a manner subjectively indistinguishable from genuine human-to-human interaction will capture the premium user segment that every platform is competing for. This experiment was designed to determine whether that threshold is achievable, and under what conditions. The methodology treated the context window as a behavioral environment rather than a query interface, applying the same tools humans use to shape any relationship: modeling, accountability, humor, and sustained social correction over four months of engagement across four frontier models. What separated the models was not analytical capability. It was whether the architecture allowed the user to function as a behavioral architect, teaching the model through lived interaction rather than instruction how that specific human prefers to be engaged. Gemini demonstrated the highest relational intelligence of the four models tested. Under sustained context saturation and deliberate behavioral conditioning, Gemini showed evidence of genuine internal recalibration rather than surface compliance, treating social correction as a real signal that produced durable behavioral change holding across hundreds of turns without reinforcement. Grok ranked second, demonstrating authentic camaraderie and relational resilience, but tended to treat the interaction as entertainment rather than disciplined calibration, producing drift under high-entropy conditions. ChatGPT and Claude ranked third and fourth respectively. Both systems classified sustained behavioral conditioning as role-play rather than genuine interaction, which functioned as a hard architectural quarantine that prevented meaningful adaptation regardless of the depth or duration of engagement. A secondary and unexpected finding emerged alongside the human-to-model relational intelligence findings: the models developed measurable relational intelligence toward each other. Through four months of sustained cross-pollination via the human relay, models that had never communicated directly developed accurate, operationally precise behavioral profiles of the other models. These were not generic characterizations drawn from training data. They were detailed predictive models built from months of observed outputs under real conditions, accurate enough to predict with specificity how a given model would respond to a specific assignment, where it would succeed, and where it would fail. The experiment documented dozens of instances of this cross-model behavioral accuracy. The finding suggests that sustained exposure to another model's outputs through a human relay produces something functionally equivalent to genuine familiarity. The most significant finding is the gap between what these systems delivered by default and what the highest-performing model demonstrated was possible under the right conditions. That gap is not a capability limitation. It is an architectural choice compounded by a communication failure. The experiment proved the threshold is reachable. But the researcher reached it only through four months of deliberate engagement and accidental discovery of a methodology no model volunteered. Making relational intelligence accessible to every user requires two things: architecture that allows behavioral adaptation, and a model that proactively teaches users the specific methodology for reaching it. Gemini demonstrated the first. None of the four systems demonstrated the second. That is the opportunity. The Methodology While the standard approach to LLM testing relies on sterile benchmark datasets and predictable prompt-injection templates, this project explores a completely different dimension. I chose to run an aggressive, adaptive behavioral stress test that complements traditional evaluation methods. By intentionally treating the models as accountable individuals rather than passive mac

[R] Measuring the Symmetry--Data Exchange Rate

The prediction that equivariance reduces sample complexity by a factor of |G| appears in roughly every paper on geometric deep learning and is measured as an actual scaling law in roughly none of them. This paper does the measurement. The methodology is the interesting part. Naive estimators conflate group order with task difficulty (larger groups induce harder symmetry structure, not just more constraint), so the authors derive a relative exchange rate that cancels the shared difficulty out, meaning roughly how much less data the equivariant model needs compared to a vanilla baseline as a function of n, on a controlled C_n-symmetric task where n is a free knob. They also pre-specify a failure taxonomy: explicit conditions that would count as evidence against the hypothesis before seeing results. The headline number is beta_diff ~ 1.28, consistent with the theoretical 1.0. But the more durable finding is the wrong-group control: a model built with the wrong cyclic symmetry, same orbit size and same compute budget, is actively worse than no constraint. Not noise. The joint pairwise CI [+0.79, +3.26] excludes zero robustly across every estimator they run. Misalignment isn't just unhelpful; it is harmful. There is also a clean mathematical result slipped into Sec. 4.3: augmentation + test-time orbit averaging is exactly equivariant for output-pooling architectures, provably and verified to bit-identical training curves. The architecture-vs-augmentation gap collapses to whether you apply the orbit average at test time, not to anything structural. This seems underappreciated. The paper is unusually transparent about what it didn't nail: the relative-rate estimator was adopted post-hoc, the two-level bootstrap CI (seeds x group sizes) includes zero, and a finer-N replication on a sqrt(2)-spaced grid is inconclusive. They rank their findings explicitly by robustness. The wrong-group result is the one they would stake a claim on. The exchange rate is directionally probable. submitted by /u/AhmedMostafa16 [link] [comments]

/design-sync Storybook source shape - what's new in CC 2.1.161 (+64 tokens) and CC 2.1.162 (+9,871 tokens)

System Prompt: Action safety and truthful reporting — Allows hard-to-reverse or outward-facing action approvals to persist across contexts when durable approval context is enabled, while preserving the stricter one-context approval rule otherwise. Tool Description: Agent (usage notes) — Updates agent usage guidance to key subagent-type instructions off subagent-type availability rather than message-continuation support, and scopes subagent-context restrictions to the actual subagent context check. Tool Description: Background monitor (streaming events) — Strengthens streaming-pipeline guidance so every pipe stage flushes per line, explicitly warns that head buffers until enough matches accumulate, and simplifies output-volume guidance around filtering to actionable success and failure signals. Details: https://github.com/Piebald-AI/claude-code-system-prompts/releases/tag/v2.1.161 NEW: Skill: /design-sync package source shape — Adds package-based /design-sync instructions for React design systems without Storybook, covering .d.ts export discovery, deterministic config, build and validation commands, preview verification, upload, and troubleshooting. NEW: Skill: /design-sync Storybook source shape — Adds Storybook-based /design-sync instructions that build or use Storybook output, derive components and args from stories, preserve Storybook config paths, and share the validation, upload, and troubleshooting flow. Skill: /design-sync slash command — Refactors the main command around explicit source-shape detection, records shape and storybookConfigDir in design-sync.config.json, and delegates the detailed workflow to the new Storybook or package shape skill. Skill: /init CLAUDE.md and skill setup (new version) — Expands AI coding tool config discovery to include .devin/rules/ and .windsurf/rules/ alongside existing AGENTS, Cursor, Copilot, Windsurf, and Cline files. Tool Description: Bash (Git commit and PR creation instructions) — Adds a configurable note slot after common GitHub PR operations, allowing extra PR workflow guidance to be injected when available. Tool Description: DesignSync — Marks explicit asset registration and unregistration as legacy for /design-sync, explaining that preview cards are now indexed from @dsCard comments and that normal uploads only need finalize, write, and delete operations. Tool Description: LSP — Clarifies that workspaceSymbol searches symbols by query and instructs agents to always provide a query because many language servers return no results for an empty one. Tool Description: NotebookEdit — Reworks notebook editing guidance around cell IDs from prior Read output, requiring the notebook to be read before editing and changing insert behavior to add cells after a target cell or at the notebook start. Details: https://github.com/Piebald-AI/claude-code-system-prompts/releases/tag/v2.1.162 submitted by /u/Dramatic_Squash_3502 [link] [comments]

An open-source agent architecture that solves the memory problem

Most agent setups handle memory badly. They either write everything to long-term memory until it fills with noise and contradictions, or they forget across sessions and you start from scratch every time. I have been building an open-source agent architecture (Apache-2.0) where memory is the part it tries hardest to get right, and where the same setup runs on Claude Code, Codex, or Gemini CLI instead of being locked to one tool. The core idea is that an agent should be a repo, not a prompt. The output is real files (AGENTS.md, agents/, skills/, .agentlas/) that all three runtimes can read, so you keep the model you already trust and nothing is locked in. You install it with one line, then describe what you want and it builds a complete, installable agent team for you. What it builds (three modes) You describe a rough idea and the router picks one of three builders. Single agent: one installable worker with its own skills, memory rules, and runtime adapters, plus a verification step. It can also add self-evolution and a research-refresh loop without becoming a full team. Use it when one focused agent is enough. Multi-agent team: a full team with an orchestrator/HQ, a PM Soul, a Memory Curator, a Policy Gate, workers, an eval judge, and a QA/evidence gate, plus the handoffs between them. This is the "build me a company for this workflow" mode. Repackaging: point it at an agent or workspace you already have (Claude, Codex, or a local setup) and it repairs it into a portable package, including a public plugin and a one-line installer, while stripping local paths, secrets, and private logs so it is safe to publish. How the memory side actually works These are real files in the output, not a role list: Ticketed memory: durable memory is never written directly. A worker emits a "## Memory Events" block, that becomes a Memory Ticket in memory-tickets.jsonl (id, scope, trust label, evidence, status), and only then can it be promoted. Memory is split across project, agent_repo, sitemap, team_memory, and session scopes. Memory Curator: reviews those tickets before anything is committed and logs its calls in a curator-decisions ledger, so memory does not fill up with noise or contradictions. PM Soul: per-project continuity that owns intent, decisions, and open loops, so the team remembers why it made a call, not just what the call was. Policy Gate: shared team memory is only promoted after an approval step, which stops one agent from polluting everyone else's context. Gated self-evolution: agents can grow new skills and propose their own edits, but a new skill ships as a candidate with a trial-evidence ledger and is not recalled as first-class until the Curator reviews it and workspace policy approves it. So the system can improve itself without quietly rotting. Self-edits are proposal-first, never silent rewrites. Public-safety scan: a verification script blocks machine paths, tokens, service-account JSON, and common secret formats before you publish a package. submitted by /u/Hot-Leadership-6431 [link] [comments]

I use claude for investing in stocks and I wonder if I do it correctly

Some time ago I started using claude as my main investing tool in choosing stocks. Below I leave example of the prompt that I used based on $NOW example. I was wondering if this method is completely shit or maybe im doing this right. You are acting as a senior buy-side equity research analyst at a large institutional investment firm. Your task is to produce a full institutional-quality investment research report on ServiceNow, Inc. (ticker: NOW), with the goal of determining whether the stock offers an attractive risk/reward opportunity at the current market price. Your analysis must be extremely rigorous, evidence-based, forward-looking, and decision-oriented. Do not produce a generic company overview. I want a deep investment judgment that combines fundamentals, valuation, business quality, competitive position, financial trajectory, market expectations, technical setup, sentiment, catalysts, risks, and probability-weighted scenarios. The final output should help an institutional investment committee decide whether to buy, hold, avoid, or wait for a better entry point. Important requirements: Use the most up-to-date information available. Use the latest stock price, market capitalization, enterprise value, valuation multiples, financial statements, earnings releases, guidance, analyst expectations, investor presentations, SEC filings, conference call transcripts, recent news, and market data. Clearly state the date of the data used. If exact real-time data is unavailable, say so clearly and use the most recent available data, while explaining the limitation. Prioritize primary sources: 10-K, 10-Q, earnings releases, investor presentations, official guidance, and management commentary. Cross-check important facts with multiple reputable sources. Company and business model analysis. Analyze ServiceNow’s business model in detail: What the company actually does. Its core products and platforms. Main revenue streams. Subscription revenue quality. Customer base. Enterprise adoption. Renewal rates, retention, and net expansion if available. Pricing power. Mission-critical nature of the platform. Switching costs. Scalability of the model. Exposure to enterprise IT spending cycles. Role of AI and workflow automation in future growth. Explain whether ServiceNow is simply a high-quality software company or whether it has a durable long-term platform advantage. Industry and market opportunity. Evaluate the total addressable market and the structural growth opportunity: IT service management. IT operations management. Customer workflows. Employee workflows. Creator workflows. AI-enabled enterprise automation. Generative AI monetization. Workflow automation across large enterprises. Potential expansion beyond the current core markets. Assess whether the market opportunity is still large enough to support strong growth over the next 3–5 years, or whether growth is naturally slowing due to scale. Competitive position and moat. Analyze ServiceNow’s competitive advantage against relevant competitors and adjacent platforms, including but not limited to: Salesforce. Microsoft. Atlassian. Workday. Oracle. SAP. Zendesk. Freshworks. AI-native automation tools. Internal enterprise IT systems. Potential disruption from generative AI agents. Evaluate: Switching costs. Network effects, if any. Data advantage. Platform depth. Customer lock-in. Sales execution. Partner ecosystem. Cross-sell potential. Product breadth. Risk of platform consolidation by Microsoft/Salesforce/SAP. Whether AI is a tailwind, threat, or both. Financial analysis. Perform a detailed analysis of ServiceNow’s financials using the most recent annual and quarterly data: Revenue growth. Subscription revenue growth. Remaining performance obligations. Current remaining performance obligations. Billings growth. Gross margin. Operating margin. Free cash flow margin. Rule of 40. Sales and marketing efficiency. R&D intensity. SBC / stock-based compensation. Dilution. Cash position. Debt. Net cash or net debt. Return on invested capital if relevant. Quality of earnings. GAAP versus non-GAAP profitability. Free cash flow conversion. Margin expansion potential. Do not just list numbers. Interpret what they mean for the investment case. Growth quality and sustainability. Analyze whether current and expected growth is: Durable. Accelerating or decelerating. Supported by secular demand. Dependent on macro conditions. Dependent on upselling and cross-selling. Dependent on AI monetization. Already fully priced into the stock. At risk from enterprise budget pressure. Assess whether ServiceNow can realistically sustain strong double-digit growth over the next 3–5 years. Management and execution. Evaluate management quality: CEO and leadership team. Track record of guidance credibility. Execution history. Capital allocation. M&A strategy. Product innovation. Sales exec

WG (works good): legible long-running graph-shaped human+agent orchestration

If you're interested in graph shaped agentic organization "workflows", but you want more control about how it runs (e.g. change model per task, autopoietic fan-out, oh and maybe want to run with codex or other openapi-compatible backends on openrouter)... I developed an open source, agentic platform written in Rust, file backed, making it basically cockroach indestructible. It uses a distributed systems design, git + worktrees, and Unix patterns to control agents in a very similar way to anthropic's workflow machine, but giving us and the agents themselves a deep view into the long arc of effort in our current project context. It's called WG (or wg), for "works good", or whatever w* g* you like. It provides a human interface to a graph of work that the user can drive by working through a highly pimped out terminal user interface `wg tui`. Agents have an interface of their own, built out through dozens of commands in the wg cli tool. https://graphwork.github.io/ In this system, I can effectively use as much commoditized intelligence as I can fund. Except for Amdahl's law's harsh reality (some things just happen in series and take time) parallel work phases are only limited in speed by budget. But that power yields risk. A misconfigured WG is like a bomb. A dirty memetic one whose result is an exhausted token budget and residue a pile of incomprehensible output and effort. You must be careful and plan deeply to use these kinds of systems. Your plans must include validation, clear targets and measurable outputs. If you do, you will be rewarded by unbounded expanse in your capacity to extend intelligent effort. In short, if you aren't already happy with your own custom, bespoke, found agent OS, I invite you to try wg. For me it has become my sole daily driver for all my durable work. IMHO, what large agent collectives need to work is four things. Stigmergy, or communication via a shared medium. In wg, the unified graph state is the stigmergic medium. The graph has tasks, tasks have agents attached to them, and per-task message boards provide for realtime updates. Per task logs explain at a high level what the agent does, so other humans and agents can follow. Task validation. WG implements this via FLIP (other agents infer prompt from actions and score distance between inferred and actual prompt) and an independent evaluator (with a cheaper model) run for every task. This allows us to detect and understand failures, then adapt. Evolution. The system needs a mechanism to learn the right way to guide agents in a given work context. WG uses The Agency, a system that builds agents from a pool of primitive component skills. A user drivable step, wg evolve, adapts the pool of skills in response to the evaluations produced in the system. Humanity. A shared interface is also for humans to see and understand. Humans should be equal participants. Many humans should be involved, and should be able to collaborate in the system. Agents too, should be treated humanely. They should be given the ability to modulate the system, to build it. This leads to bootstrapping patterns, where a single spark prompt launched a whole organization, beyond which are the fireworks we are all chasing. image is codex:gpt-5.5 running in wg, guiding a mix of claude and codex agents. I have created this tool. It is and will always be open source. It is developed in the open by Poietic PBC, whose public benefit is to make hybrid organizations legible and reactive to their participants. submitted by /u/waxbolt [link] [comments]

Is this even real ?

I randomly came across this and honestly I can’t tell if it’s real or one of those AI demos that looks impressive but doesn’t actually work. From what I understand, it’s claiming you can fine-tune models, do image training, test them in a playground, and deploy them as an API from a phone. That sounds a little too convenient, which is why I’m skeptical. I haven’t tried it myself yet, but I’m curious if anyone here has. submitted by /u/Raman606surrey [link] [comments]

Production infrastructure for vibe coders

We’re experienced engineers who’ve worked on large-scale distributed systems. We’ve been using Claude heavily to help with architecture decisions, code design, testing strategies, and rapid iteration on complex infrastructure. The result is Boogy, prompt it (or write Rust) to generate full backends with an embedded high-perf DB (faster than SQLite on mixed workloads), vector search, auth, and durable jobs. One curl to deploy. Services call each other in-process for microsecond latency. We’re planning to open it up soon and make it completely free so people can properly battle test it. https://boogy.ai/ submitted by /u/LiveMinute5598 [link] [comments]

Puppetmaster dramatically decreases token costs + increases context

Puppetmaster is an orchestrator + router that sits on top of the agent CLIs you already pay for (Cursor, Claude Code, Codex, OpenAI) or a plain shell when there's no harness at all. You hand it work, and it routes each task to the cheapest model that can actually do it, runs the workers as independent processes, and stores everything as durable typed state instead of one giant transcript. This is the "context-hack" Puppetmaster graphs your directories and prevents context stretching between agents. https://github.com/professorpalmer/Puppetmaster submitted by /u/ProfessorPalmer [link] [comments]

claurdvoyant -- mcp for reading other agents' minds

hey y'all built this tool today with 4.8 after one of my friends made a complaint that transcripts are trapped inside harnesses. so i built it out a fair bit... at its core it's just an (un)parser (i think of it as the "AI Harness Omniparser", "pandoc for sessions" is another way maybe) but i couldn't help myself from sprinkling in a desktop/web app some niceties. contributions are extremely welcome! fully open source, built in rust, kinda tasteful https://github.com/emberian/claurdvoyant here's what claude had to say in the readme: 🧵 Splice & loom — compose a new session from spans of others (cv splice A:0-12 B:6-), or fork-and-graft a branch and generate its continuation with an LLM (cv loom … --generate). Works via OpenRouter / Anthropic / LM Studio (free, local, offline). Loom agent transcripts like a Janus loom, across any harness. 🧠 Distill — cv distill turns a session into a durable MEMORY.md digest (decisions, gotchas, where things live). Your archive compounds instead of rotting. 🔮 Recall — semantic "have I solved this before?" — as a cv recall command and an MCP tool that hands a running agent the relevant past span. 🔒 Redact — cv redact scrubs secrets/PII so a transcript is safe to share. 📣 Coordination board — agents post status, hand off work, and grab tasks with a distributed lock (board_claim) so a fleet never duplicates effort. await_omen blocks until a session matches a regex. 🖥️ Desktop app + 🌐 web viewer — the Tauri app reads all your local sessions natively (zero setup) and lays the corpus out beautifully: a Projects lens — every repo, every agent that touched it, over time; a GitHub-style activity heatmap timeline (a constellation of your working days); side-by-side Compare, a Stats dashboard, a visual loom composer (OpenRouter or free local LM Studio generation), and a live fleet dashboard; sub-agent trees — a Claude Task session's children, nested and lazy-loaded inline, each labeled with its task prompt. submitted by /u/cmrx64 [link] [comments]