Multi Agent Systems

16 posts

toss5 min readCurated summary

Getting AI to Provide Investment Information

LLMs make it easy to generate financial content, but producing trustworthy investment information requires much more than fluent summaries. Toss Securities argues that AI must pass three gates before reaching users: selecting reliable evidence, controlling how responses are generated, and making outputs measurable and improvable. The central principle is to constrain AI autonomy where reproducibility and traceability matter, while preserving it for open-ended exploration. ## Why Investment Information Is Different - **Timeliness:** Market interpretations can change within hours due to earnings, geopolitical events, or policy news. - **Accuracy:** A company mentioned in an article may not be the company whose stock moved; it could be a subsidiary, a similarly named firm, or merely a promotional mention. - **Traceability:** Every generated claim needs supporting evidence, evaluation records, and reproducible processing. - **Non-stationarity:** Market behavior changes across earnings seasons, interest-rate events, elections, and geopolitical crises. Prompts and models tuned to one period may degrade later. LLMs and autonomous agents amplify these challenges: - LLMs can produce fluent but incorrect answers when evidence is incomplete or ambiguous. - Agents add more failure points through search, tool calls, planning, and state transitions. - Errors can propagate through different execution paths, increasing operational cost and making debugging difficult. ## Gate One: Selecting What the AI Should Say The first gate is a context-engineering process that filters and organizes evidence before it reaches the LLM. ### Classify Data at Ingestion - News, disclosures, and financial data are classified as they arrive using internally developed BERT-based models. - Metadata includes: - Taxonomy tags - Related companies and entities - Embeddings for vector search - Pre-classifying data avoids waiting until retrieval to determine whether it is relevant. ### Retrieve Broadly, Then Narrow the Candidates A hybrid retriever first prioritizes recall, after which candidates are reduced through: - **Deduplication:** Semantically similar articles are clustered so one event is not treated as many independent events. - **Reranking and filtering:** Evidence is evaluated for direct relevance to the company’s price movement. - **Taxonomy labels:** Items are categorized by explanation type, such as earnings, guidance, or corporate actions. - **Failure labels:** Promotional content, insufficient evidence, and other unsuitable sources are explicitly marked and filtered out. - **Rubrics:** Evidence is ranked according to predefined relevance criteria. ### Build Reasoning-Friendly Context The final context is arranged so the model checks: - What happened - How the event connects to the target company - Whether the evidence’s polarity matches the stock’s price direction - Whether the evidence is sufficient and current This ordering combines the filtered evidence with metadata such as the company, price direction, and time window. ## Gate Two: Controlling How Responses Are Generated The second gate limits the action space of LLMs and agents to satisfy product requirements such as cost, latency, reproducibility, and observability. ### Use Task Graphs for Clearly Defined Work Instead of leaving the entire process to an autonomous agent, Toss Securities separates it into explicit stages: - Candidate retrieval - Relevance assessment - Deduplication - Evidence construction - Final response generation Each stage has defined input and output schemas, making it a debugging and evaluation point while simplifying fallbacks and operational monitoring. ### Choose Autonomy Based on Requirement Clarity - **Autonomous agents** are useful for open-ended tasks such as discovering investment ideas or exploring possible market scenarios. - **Procedural orchestration** is better for fixed tasks, such as explaining why a specific stock moved. - Long ReAct loops increase tool calls, token usage, latency, and trace-management costs. - For structured products, deterministic pipelines let LLMs focus on summarization, rewriting, and evidence-based explanation rather than tool selection. Procedural graphs are not merely a replacement for agents. Once defined, they can become reusable tools or sub-agents that other agents call through structured interfaces, such as: ```text input: ticker, direction, time_window output: explanation, evidences, reasoning_type ``` ## Gate Three: Making the System Evaluatable Subjective judgments such as “the answer feels weak” do not provide a reliable improvement loop. The system therefore generates structured classifications alongside natural-language responses. ### Generate Rubric Categories with Each Answer - Outputs include event or reasoning types and failure categories. - Structured fields make it possible to measure: - Relevance false positives - Directional mismatches - Irrelevant evidence passing the filter - Precision, recall, and F1 score - The taxonomy must evolve as new market regimes and failure patterns appear. - Operational failures, evaluation sets, prompt versions, and model versions should be linked so improvements can be reproduced and quantified. ### Retrieve Context-Specific Few-Shot Examples Fixed few-shot examples are insufficient because event and failure types vary widely across market conditions. Instead: - Store operational samples with their decisions, failure labels, and embeddings. - Embed each new classification or verification task. - Retrieve similar positive and negative examples. - Include both successful and failed examples to show the model the decision boundary. This approach reuses production failures as future evaluation guidance and significantly improves precision and accuracy while preserving recall. Since false positives are especially damaging in investment services, filtering out unsupported explanations is more important than producing fluent text alone. ## Work Beyond Prompts and Model Training Building an investment-information AI service also requires substantial infrastructure outside the model itself: - Retrieval strategies and embedding models for finding relevant evidence - Separately trained classifiers for categorization - Evidence filtering, validation, and metadata management - Structured orchestration, monitoring, evaluation, and feedback loops The practical recommendation is to treat the LLM as one component in a controlled evidence pipeline—not as the sole decision-maker. Use autonomous agents for exploratory tasks, but rely on traceable procedural graphs, evolving taxonomies, and retrieval-based examples when the product must deliver repeatable, defensible financial information.

Read original(opens in new tab)
aws3 min readCurated summary

Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore | Amazon Web Services

Amazon Bedrock AgentCore Runtime Instances provides persistent, managed compute for production AI agents that need more than short-lived invocations. It supports multi-day workflows, shared state, GPU acceleration, multi-agent collaboration, and direct OS access while AWS manages the underlying EC2 infrastructure. Runtime Instances complements AgentCore’s lightweight microVMs, enabling teams to combine fast-scaling orchestration with persistent worker environments. ## Why Persistent Compute Matters - Production agents often run for hours or days and must preserve state across workflow steps. - Complex systems may require: - Collaboration between multiple agents - Shared files and context - GPU acceleration - Direct operating-system access - Continuous execution across multiple days - Previously, teams had to provision EC2 instances, configure networking, manage sessions and scaling, and build monitoring themselves. ## What Runtime Instances Provides - AWS-managed EC2 infrastructure for hosting multiple agents in one runtime. - Shared sessions that persist for up to 14 days. - Separate dependencies and artifacts for each deployed agent. - GPU-capable infrastructure for compute-intensive workloads. - Session stop and restart capabilities to reduce idle costs. - Support for zip packages and container images. - Compatibility with frameworks such as CrewAI, LangGraph, LlamaIndex, and Strands. - Integration with existing AgentCore APIs, identity controls, and observability. - Persistent knowledge storage through Amazon EBS and AgentCore Memory. ## Combining MicroVMs and Runtime Instances - Runtime microVMs remain useful for lightweight orchestrator agents that need rapid scaling. - Runtime Instances are better suited to persistent, resource-intensive workers. - An orchestrator can: - Route tasks to specialized agents - Make API calls - Aggregate results - Instance-based workers can handle tasks such as code compilation, security scanning, or GUI automation while retaining local state. ## Shared-Filesystem Agent Example The demonstration uses two Strands Agents applications: - A code writer: - Generates Python code from a natural-language task. - Saves the result as `code.py` in a session-specific shared directory. - A code reviewer: - Reads the writer’s file from the same filesystem. - Reviews it for bugs, style issues, and suggestions. - Both applications use: - An `@app.entrypoint` decorator - A selected Bedrock model - The session ID to identify shared storage - Because both agents share the host filesystem, they exchange artifacts without API calls or explicit data transfer. ## Deployment Workflow ### Create a Capacity Provider - Select the operating system, allowed EC2 instance types, VPC, subnets, and security groups. - The example uses: - Linux 64-bit ARM - `c7g.2xlarge` - 8 vCPUs and 16 GiB of memory - A default `gp3` volume - AgentCore creates or assigns the required infrastructure role and instance profile. - Once active, most capacity provider settings cannot be changed, so configuration should be verified beforehand. ### Create a Runtime and Deploy an Agent - Create a runtime using the **Instances** compute type. - Associate it with the capacity provider. - Upload the agent package to Amazon S3. - Specify the language runtime, such as Python 3.13, and the entry-point file containing `@app.entrypoint`. - Deployment can be performed through the AWS Management Console, AgentCore CLI, AWS CLI, or infrastructure as code. Runtime Instances are a strong fit for agents with long-running, stateful, collaborative, or compute-heavy workloads. Use them alongside microVMs when a system needs both elastic orchestration and persistent worker infrastructure, while relying on EBS or AgentCore Memory for state that must outlive individual sessions.

Read original(opens in new tab)
line4 min readCurated summary

Unifying Analysis Through the Power of Analytics Agents: Work Innovation and Role Transformation in the Generative AI Era at a Professional Organization

PJ One Piece is LY Corporation’s initiative to connect business questions, data analysis, insight generation, and next-action planning through generative AI. Its analysis agent reduced typical turnaround times from about two weeks to roughly 10 minutes, enabling hundreds of analyses each month and adoption by more than half of an early-adopter business unit. The project treats AI not as a chat interface, but as an analysis platform that connects data, knowledge, people, and organizational processes. ## Three Disconnects Behind the Project - **Business and data:** Even with a data warehouse and BI tools, business users still needed to understand SQL, tables, column definitions, KPI rules, and result interpretation. - **Within the analysis process:** Task definition, analysis design, execution, review, and action planning were often handled by different people or tools, causing context loss, rework, delays, and inconsistent quality. - **Across domains:** Useful analysis patterns and domain knowledge remained isolated because services used different KPIs, table structures, business assumptions, and review criteria. ## The Analysis Agent as a Connector - Users ask questions in natural language without needing to know SQL or database structures. - The agent: - Clarifies the business objective and missing assumptions. - Finds relevant data and creates an analysis plan. - Executes queries and specialized analyses. - Interprets results and produces visualizations or reports. - Suggests further analysis and possible next actions. - The platform consists of: - A user-facing application. - An LLM-based agent for reasoning and tool use. - Tools for SQL, Python, document search, and visualization. - A knowledge base containing domain information, skills, and table metadata. - Logging, feedback, monitoring, and evaluation systems. - Domain knowledge is added through a plugin-like structure, while logs and feedback continuously improve the system. ## Turning Business Questions into Analysis Requirements - Natural-language questions often leave important assumptions unspecified, such as: - Target population or campaign definition. - Analysis period and comparison group. - KPI definitions. - Aggregation level. - Exclusion conditions. - Rather than requiring users to write detailed prompts, the agent uses domain knowledge to determine what can be inferred and asks only about unresolved points. - Knowledge bases document service context, KPI definitions, aggregation cautions, policy information, and review requirements. - Table metadata explains available tables, columns, appropriate use cases, samples, partition requirements, and usage restrictions. ## Reaching Data Safely and Reliably - Table metadata is revealed progressively: - The agent first narrows down relevant tables. - It then retrieves detailed definitions and usage rules only for those tables. - Analysis-oriented wide tables or logical views combine transaction data with commonly needed attributes, reducing complicated joins and SQL-generation errors. - SQL is checked before and after execution to enforce: - `SELECT`-only access. - Approved tables and usage rules. - Required partition conditions. - Restrictions on sensitive or personal data. - Result-size limits. - These guardrails allow the agent to perform analysis flexibly without exposing data or infrastructure to unnecessary risks. ## Preserving Context Across the Analysis Process - PJ One Piece uses a supervisor-style multi-agent architecture. - A main agent maintains: - The user’s request and business objective. - The current analysis plan. - Findings and constraints discovered so far. - Remaining questions and decision points. - Specialized sub-agents handle tasks such as statistical testing, time-series analysis, clustering, and independent review. - This separates complex or specialized work from the main context while preserving overall continuity. - Progress updates expose discoveries, design decisions, data limitations, and constraints so users can adjust direction during longer analyses. ## Building Reusable Organizational Capability - Logs record agent actions, assumption checks, analysis designs, generated SQL, errors, and outputs. - User and analyst feedback helps identify whether improvements are needed in prompts, tools, data, or reusable skills. - Repeated workflows are formalized as skills, including: - General-purpose methods such as time-series and clustering analysis. - Domain-specific workflows such as monthly reporting or policy monitoring. - Skills document required assumptions, comparison axes, cautions, and interpretation methods. - Over time, isolated domain knowledge becomes reusable organizational analysis capability. ## Business Impact - In early deployment, the platform expanded data use beyond data scientists to product owners and frontline employees. - More than half of the participating business unit’s members use it. - Analysis turnaround fell from an average of approximately two weeks to about 10 minutes. - The platform now supports hundreds of analyses per month and serves as a daily starting point for business questions. PJ One Piece’s main recommendation is to design AI analysis as an end-to-end operating platform—not merely an automated SQL or chatbot tool. Combining structured domain knowledge, safe data access, contextual multi-agent workflows, reusable skills, and continuous evaluation can make analysis faster while steadily improving its quality and organizational reach.

Read original(opens in new tab)
google3 min readCurated summary

Unlocking dependable responses with Gemini Enterprise Agent Platform’s Agentic RAG

Google’s Agentic RAG framework extends traditional retrieval-augmented generation to handle complex, multi-source enterprise questions. Its multi-agent system plans searches, rewrites queries, routes them across data sources, and iteratively retrieves missing information instead of stopping after one pass. A Sufficient Context Agent verifies that the evidence supports every part of the request, improving factual accuracy by up to 34% on evaluated datasets. ## Why Standard RAG Falls Short - Conventional RAG typically performs one retrieval step before generating an answer. - Enterprise information is often distributed across separate data sources and requires multi-hop reasoning. - For example, a project document may contain a server ID, while the server’s specifications exist in another database. - Without a second search, the system may produce an incomplete answer or incorrectly conclude that the information is unavailable. ## Multi-Agent Planning, Rewriting, and Routing The framework divides research into specialized roles: - **Orchestrator:** Determines whether the request requires multiple steps and delegates tasks. - **Planner Agent:** Maps the information needed and identifies which sources to search. - **Query Rewriter:** Converts a broad question into targeted search queries. - **Search Fanout Agent:** Sends those queries to multiple retrieval systems. - **Synthesis Agent:** Combines the gathered evidence into the final response. This architecture is designed to coordinate complex searches rather than treat retrieval as a single matching operation. ## Iterative Retrieval with Sufficient Context The central innovation is persistence: the system detects when its evidence is incomplete and continues searching. - The **Sufficient Context Agent** reviews: - Retrieved text snippets - An intermediate draft answer - The original user request - It identifies which requested elements are supported and which are missing. - Instead of merely reporting insufficient information, it produces specific feedback describing the gap and suggesting what to search for next. - This feedback drives another query-rewriting and retrieval cycle. - Retrieval stops only when the system determines that the available context is sufficient for a grounded answer. ## Example: Patient Discharge Information For a request involving medications, dietary restrictions, and allergic reactions, the workflow proceeds as follows: - The Root Agent delegates the task to Pharmacy, Nutrition, and Clinical Notes sub-agents. - The initial search finds medication and diet information but no obvious allergy records. - The Sufficient Context Agent flags the missing allergy information. - The Query Rewriter generates focused searches such as “rashes” or “adverse events.” - A deeper search finds the missing evidence. - The system performs a final context check before producing the doctor’s summary. ## Evaluation Results - The framework was evaluated on the FramesQA benchmark, which contains multi-hop questions. - It reportedly improved factuality accuracy by up to 34% compared with standard approaches. - Google also tested it on proprietary internal datasets and observed better grounding and reasoning accuracy across several domain-specific tasks. - The approach is hosted through Gemini Enterprise Agent Platform’s Cross-Corpus Retrieval capability. Agentic RAG is most useful when answers depend on several documents, databases, or reasoning steps. For enterprise deployments, iterative retrieval and explicit context verification can reduce incomplete answers and unsupported guesses, though they add orchestration and retrieval overhead.

Read original(opens in new tab)
google3 min readCurated summary

A New Era of Innovation: Google Research at I/O 2026

Google’s I/O 2026 research announcements present AI as an “agentic” amplifier of human ingenuity, particularly in science and healthcare. New systems such as Gemini for Science, ERA, Co-Scientist, and Gemini Deep Think are designed to generate hypotheses, write and optimize code, evaluate evidence, and solve difficult research problems. Google also highlighted health-focused AI that supports users before, during, and after medical visits, while emphasizing collaboration, validation, and responsible deployment. ## AI-Driven Scientific Discovery - **Gemini for Science** is a suite of experimental tools built from Google Research and developed with Google Cloud, Google DeepMind, and Google Labs. - **Empirical Research Assistance (ERA)** acts as a code-optimizing research engine: - Proposes concepts and writes software. - Evaluates results against a defined scoring system. - Uses tree search to test thousands of code variants. - Has supported work in neuroscience, cosmology, respiratory-illness forecasting, and California runoff prediction. - **Co-Scientist** is a Gemini-based multi-agent collaborator that generates, evaluates, and refines hypotheses. - Researchers have applied it to antimicrobial resistance, plant immunity, and liver fibrosis. - **Computational Discovery**, combining ERA and AlphaEvolve, runs thousands of code variations in parallel to test scientific models and hypotheses more quickly. - **Hypothesis Generation** uses a multi-agent “idea tournament” to debate and rank research ideas, with clickable citations supporting claims. - **Literature Insights**, powered by NotebookLM, helps researchers synthesize large bodies of scientific literature. - **Science Skills** can automate specialist workflows such as structural bioinformatics and genomic analysis on agentic coding platforms. ## AI for Peer Review and Advanced Reasoning - Google is piloting the **Paper Assistant Tool (PAT)** for scientific peer review. - PAT has experimentally reviewed more than 10,000 papers for conferences including ICML, STOC, and NeurIPS. - Its feedback has helped authors identify theoretical gaps and design additional experiments. - **Gemini Deep Think** has been used with mathematicians, physicists, and computer scientists to address open problems involving network deadlocks, optimization, machine-learning behavior, auction theory, and cosmic-string singularities. ## Advancing Health with AI - Google’s health research focuses on supporting people throughout the full healthcare journey, from understanding symptoms and preparing for appointments to interpreting medical records. - Research contributions underpin the **Google Health app** and **Google Health Coach**, with the app beginning rollout to existing Fitbit users. - **Symptom AI** investigates how conversational AI can reason about information relevant to a person’s symptoms. - A Fitbit-based study included 13,917 participants. - In blind comparisons, clinicians preferred Symptom AI’s differential diagnoses roughly twice as often as those produced by other clinicians. - The **Plan for Care** pilot involved 1,779 participants preparing for doctor visits. - Compared with baseline systems, 15% more users felt prepared. - 13% more users felt confident they could make effective use of their appointment. - Google is also studying personal health large language models and the use of personal health record data to improve health guidance. Google’s announcements point toward research systems that actively experiment, collaborate, and reason rather than merely retrieve information. Their practical value will depend on continued scientific validation, clinician involvement, privacy protections, and careful expansion from experimental tools into real-world use.

Read original(opens in new tab)
figma2 min readCurated summary

How to Design Agentic Tools for Work | Figma Blog

Gemini Enterprise is designed to make complex, multi-agent business workflows feel simple without hiding AI’s role. Its core principle is to keep users focused on goals while making intervention, accountability, and data context visible. The result is an agentic system that supports not only individual productivity but shared team intelligence. ## A Familiar Brand with Business-Specific Capabilities - Gemini Enterprise shares Gemini’s visual language, including the sparkle icon, gradients, rounded shapes, and motion. - Its enterprise experience emphasizes integrations with tools such as Google Workspace, Jira, and Notion. - Connectors are made prominent in the prompt experience so agents can access the business context needed to produce useful results. ## Moving Beyond Chat with the AI Inbox - Enterprise work often involves multiple tools, data sources, deadlines, and agents working simultaneously. - The AI Inbox provides a visual overview of: - Tasks agents are currently handling - Completed work - Items requiring human intervention - Deliverables awaiting review - This dashboard is intended to feel more like a team status check-in than a sequence of chat messages. ## Collaborative Projects as Shared Workspaces - Gemini Enterprise replaces isolated chat threads with persistent, shared project spaces. - AI participates as a visible team member by: - Performing tasks - Summarizing discussions - Finding project files - Answering questions about shared material - Requests are attributed to individual team members, improving accountability and helping others understand the context behind an agent’s actions. - Shared spaces reduce information silos by allowing teammates to discover and use one another’s uploaded materials. - The assistant becomes a single source of truth and a “team intelligence amplifier,” rather than merely a personal productivity tool. ## Multiple Modes of Team Interaction - Teams can communicate with AI in group chats within Collaborative Projects. - In Canvas Mode, the assistant can generate and edit documents. - These modes allow AI to remain embedded in ongoing team workflows instead of being limited to isolated prompts. Gemini Enterprise’s design recommendation is to combine powerful orchestration with clear visibility and human control. Agents should work proactively, but their actions, sources, status, and opportunities for intervention must remain understandable to the people responsible for the outcome.

Read original(opens in new tab)
slack4 min readCurated summary

Managing context in long-run agentic applications

Long-running multi-agent applications cannot rely on unlimited conversation history: model APIs are stateless, and growing context windows eventually reduce quality or hit hard limits. Slack’s security-investigation system addresses this by giving agents complementary, purpose-specific context rather than exposing every agent to the full investigation history. Its three main channels—the Director’s Journal, Critic’s Review, and Critic’s Timeline—preserve coherence while leaving room for independent reasoning. ## The Challenge of Long-Run Coherence - Agent frameworks usually maintain continuity by resending the complete message history with every inference request. - Long investigations can involve hundreds of requests and megabytes of generated output. - Context windows impose both: - A hard limit on how much history can be supplied. - A quality limit, because performance may degrade before the window is completely full. - Multi-agent systems need carefully scoped views: - Too little shared context makes agents disconnected from the investigation. - Too much shared context can suppress creativity and encourage confirmation bias. ## Three Complementary Context Channels Slack uses separate information sources for different purposes: - **Director’s Journal** - Structured working memory for the orchestrating Director. - Records decisions, observations, findings, questions, actions, and hypotheses. - **Critic’s Review** - An annotated report evaluating Expert findings. - Includes credibility scores to distinguish reliable evidence from weaker claims. - **Critic’s Timeline** - A consolidated chronological view of findings. - Also attaches credibility scores, helping agents understand the sequence and evidential strength of events. Together, these channels provide continuity without forcing every agent to process the entire raw conversation. ## The Director’s Journal The Director coordinates the investigation by choosing questions, assigning specialist Experts, assessing progress, and deciding when to stop. The Journal gives it persistent working memory across phases and rounds. - The Director is encouraged to update the Journal frequently with short notes. - Entries can represent: - **Decisions** about investigative strategy - **Observations** about emerging patterns - **Findings** representing confirmed facts - **Questions** that remain unresolved - **Actions** taken or planned - **Hypotheses** about what may be happening - Entries can also include: - Priority levels - Follow-up actions - References to supporting evidence - Investigation phase, round number, and timestamp - The journaling tool itself simply accumulates entries; the agents’ prompts explain how to interpret them. ## Maintaining Alignment Across Agents - The Journal creates a shared narrative around the Director’s evolving plan. - It helps the Director: - Track progress - Identify dead ends - Revise investigative direction - Preserve decisions between rounds - Guide other agents toward a conclusion - Every agent receives the current Journal chronologically, along with instructions describing: - The Director’s role - Each agent’s relationship to the Director - The Journal’s purpose - How its entries should influence their work - This approach keeps specialists anchored to the overall investigation without requiring them to read every prior interaction. ## Example Investigation Context The sample Journal comes from an investigation into an apparent kernel-module-loading alert that turned out to be a false positive. - The Director recorded that: - The event originated from a package-installation hook rather than a direct `modprobe` command. - The host appeared to be a personal development workstation. - Root access was expected in that environment. - The detection rule matched “kmod” in a script path rather than confirming module loading. - The Director identified relevant Expert domains, including: - Endpoint telemetry - Identity and access - Configuration management - User behavior - The Journal captured both the preliminary conclusion and remaining verification tasks, such as checking the parent process chain. The design therefore preserves the reasoning trail while keeping it structured and compact. A practical design for long-running agentic systems is to replace indiscriminate transcript accumulation with multiple, curated context channels. Persistent journals can maintain leadership and continuity, while independent reviews and timelines provide evidence-focused context without overwhelming agents or biasing their reasoning.

Read original(opens in new tab)
google3 min readCurated summary

Improving the academic workflow: Introducing two AI agents for better figures and peer review

AI is being positioned as an active participant in academic research, not merely a tool for drafting text. The post introduces PaperVizAgent, which creates publication-ready figures, and ScholarPeer, which produces literature-grounded peer reviews. Both use multi-agent workflows and iterative verification to reduce researchers’ administrative burden while improving visual quality and review rigor. ## PaperVizAgent: Generating Publication-Ready Figures - PaperVizAgent converts manuscript text and a detailed figure caption into academic illustrations. - It uses five specialized agents: - **Retriever:** Finds relevant literature and reference figures. - **Planner:** Organizes the technical content. - **Stylist:** Develops appropriate visual and aesthetic guidelines. - **Visualizer:** Produces images or executable Python code for statistical plots. - **Critic:** Checks the result against the source text and requests revisions. - The critic-driven refinement loop is designed to ensure that figures are both technically faithful and visually clear. - Inputs typically include: - The manuscript’s method or technical sections. - A communicative-intent description explaining what the figure should convey. ### Evaluation Results - PaperVizAgent was compared with direct prompting, few-shot prompting, GPT-Image-1.5, Nano-Banana-Pro, and Paper2Any. - Figures were scored from 0 to 100 on: - Faithfulness - Conciseness - Readability - Aesthetics - It achieved an overall score of **60.2**, exceeding the human baseline of **50.0** and outperforming the evaluated automated systems. - Its strongest results were in conciseness and aesthetics, while its statistical plots reached human-competitive quality. ## ScholarPeer: Automating Rigorous Peer Review - ScholarPeer is a search-enabled, context-aware multi-agent system designed to emulate the workflow of a senior academic reviewer. - Rather than treating review as simple text generation, it combines literature retrieval, adversarial checking, and technical verification. - Its main components include: - A **sub-domain historian** that builds a current domain narrative from literature. - A **baseline scout** that searches for overlooked datasets, methods, and comparisons. - A **multi-aspect Q&A engine** that tests novelty and technical claims. - A **review generator** that follows conference-specific review guidelines. - The resulting review includes a summary, strengths, weaknesses, and questions for the authors. ### Evaluation Results - ScholarPeer was evaluated on public datasets against fine-tuned models and other agentic reviewing systems. - Its active web-search and verification process produced highly critical reviews grounded in existing research. - Side-by-side evaluations showed strong win rates against competing automated reviewers. - The system also narrowed the gap between AI-generated reviews and human reviews in terms of realism, diversity, and alignment with expert judgments. ## Implications for Academic Research - The two agents address separate bottlenecks in the publication process: - PaperVizAgent improves technical communication through better figures. - ScholarPeer helps scale peer review amid growing submission volumes and reviewer fatigue. - Their multi-agent designs suggest that specialized agents, coordinated through retrieval and iterative critique, may be more effective than a single general-purpose language model. - The systems are intended to support researchers rather than replace scientific judgment. Researchers could use PaperVizAgent for early figure prototyping and ScholarPeer for preliminary, literature-informed critique, while retaining human oversight for final scientific and editorial decisions.

Read original(opens in new tab)
github3 min readCurated summary

Run multiple agents at once with /fleet in Copilot CLI

GitHub Copilot CLI’s `/fleet` command lets multiple subagents work on independent tasks simultaneously rather than completing everything sequentially. An orchestrator decomposes the objective, manages dependencies, dispatches agents, and verifies their results. To benefit from parallel execution, users should define clear deliverables, boundaries, dependencies, and validation requirements. ## How `/fleet` Works - Breaks a task into discrete work items and identifies dependencies. - Runs independent items in parallel as background subagents. - Waits for completed work before dispatching dependent tasks. - Verifies results and assembles the final output. - Gives each subagent its own context window while sharing the same filesystem. - Prevents direct communication between subagents; the orchestrator coordinates them. ## Getting Started - Run `/fleet <objective prompt>` interactively, such as: ```bash /fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/ ``` - For terminal-based non-interactive use: ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - The `--no-ask-user` option is required when no one is available to answer prompts. ## Writing Parallelizable Prompts - Define concrete deliverables such as individual files, test suites, or documentation sections. - Avoid vague requests that make it difficult to identify independent work. - Explicitly state: - File or module ownership - Constraints, such as avoiding dependency changes - Required tests, linting, or type checks - List dependencies so the orchestrator can serialize only the necessary work while parallelizing the rest. ## Using Custom Agents - Specialized agents can be defined in `.github/agents/`. - Agent definitions may specify: - Model - Tools - Role-specific instructions - Prompts can assign different agents to different tracks, such as using a technical writer for documentation and the default agent for code. - If no model is specified, the agent uses the current default model. ## Monitoring Fleet Execution - Review the initial decomposition to ensure the task has multiple independent tracks. - Use `/tasks` to inspect active background work. - Look for progress updates from separate tracks. - If work is proceeding sequentially, ask Copilot to decompose the task first and report each track’s status and blockers. ## Avoiding File Conflicts - Subagents share a filesystem without file locking. - If two agents edit the same file, the last completed write silently overwrites the other. - Assign distinct files or directories to each track. - For shared files, use temporary outputs and merge them afterward, or impose an explicit execution order. Use `/fleet` for well-partitioned work with clear ownership and dependencies. Careful prompt structure is essential: parallelism is most effective when agents can operate independently without competing for the same files.

Read original(opens in new tab)
github3 min readCurated summary

How Squad runs coordinated AI agents inside your repository

Squad is an open-source GitHub Copilot project that places a preconfigured team of AI agents directly inside a repository. Rather than relying on a single chatbot or complex orchestration infrastructure, it coordinates specialized agents for design, implementation, testing, documentation, and review. Its core argument is that repository-native, versioned context makes multi-agent development more accessible, inspectable, and resilient. ## Coordinating Specialized Agents - Install Squad with `npm install -g @bradygaster/squad-cli`, then run `squad init` in a repository. - The setup creates roles such as lead, frontend developer, backend developer, tester, and documentation specialist. - A coordinator interprets natural-language requests, loads repository context, and assigns work to specialists. - Agents can work in parallel, create files and branches, write tests, and open pull requests. - They use shared decisions and project history rather than requiring every detail to be repeated in prompts. - Testing and review happen within the workflow: - Testers evaluate implementations and reject failing code. - A rejected author is prevented from revising its own work. - Another agent must address the problems, providing a more independent review. - Developers still answer questions, correct assumptions, and review and merge pull requests; Squad is collaborative orchestration rather than full autonomy. ## Repository-Based Shared Memory - Squad uses a “drop-box” model instead of depending on live chat synchronization or complex vector databases. - Architectural decisions, library choices, and conventions are appended to a versioned `decisions.md` file. - This creates: - Persistent shared knowledge - An understandable audit trail - Recovery after disconnects or restarts - Memory that can be reviewed and changed like code ## Replicating Context Across Agents - The coordinator remains a thin router instead of attempting to manage all implementation work. - Each specialist runs in its own inference call with an independent context window. - This replicates relevant repository context across agents rather than splitting one limited context among multiple roles. - Parallel, independent contexts reduce the risk that project-management instructions and other agents’ reasoning crowd out the actual coding task. - Supported models may provide context windows of up to 200,000 tokens. ## Versioned Agent Identities and History - Each agent’s behavior is primarily defined by repository files: - A charter describing its role and responsibilities - A history recording previous work - Shared team decisions - These files live in `.squad/` alongside the application code. - Cloning a repository also restores the team’s accumulated knowledge, making the agents effectively pre-onboarded. - Keeping memory in plain text makes it inspectable, versioned, and independent of hidden model state. ## Lowering the Barrier to Multi-Agent Development Squad’s main goal is to make agentic workflows practical without requiring users to build orchestration layers, configure databases, or master advanced prompt engineering. Its repository-native design favors simple setup, transparent memory, independent review, and recoverable project context. Developers interested in this approach can install Squad and experiment with it directly in the project repository.

Read original(opens in new tab)
github2 min readCurated summary

Multi-agent workflows often fail. Here’s how to engineer ones that don’t.

Multi-agent workflows often fail because agents make implicit assumptions about state, ordering, and intended actions. The post argues that these systems should be engineered like distributed software rather than treated as chat interfaces. Typed schemas, explicit action definitions, and MCP-enforced interfaces make agent behavior more predictable and failures easier to contain. ## Typed Schemas Prevent Data Drift - Natural-language exchanges and inconsistent JSON lead to changing field names, mismatched types, and ambiguous payloads. - Typed interfaces define machine-checkable contracts, such as a `UserProfile` with fixed fields and allowed plan values. - Schema violations can fail fast, triggering retries, repairs, or escalation before invalid state spreads. - Debugging becomes contract-based instead of dependent on inspecting logs and guessing. ## Action Schemas Clarify Intent - Agents cannot reliably infer what “take action” means; they may assign, close, escalate, or do nothing. - Action schemas restrict outcomes to explicit, valid choices such as: - Requesting more information - Assigning an issue - Closing an issue as a duplicate - Taking no action - A discriminated union or similar structure ensures every agent returns one recognized action. - Invalid or ambiguous actions can be rejected, retried, or escalated. ## MCP Enforces Agent Interfaces - Schemas and action definitions are only conventions unless consistently enforced. - Model Context Protocol (MCP) provides explicit input and output schemas for tools and resources. - Calls are validated before execution, preventing agents from inventing fields, omitting required inputs, or drifting between interfaces. - MCP therefore acts as the enforcement layer for both data structure and intended behavior. Reliable multi-agent systems require explicit contracts at every boundary. Engineers should treat agents like code components: define their data and actions precisely, enforce interfaces with mechanisms such as MCP, and prevent invalid state from propagating.

Read original(opens in new tab)
spotify3 min readCurated summary

Our Multi-Agent Architecture for Smarter Advertising | Spotify Engineering

The post argues that fragmented advertising workflows, not backend infrastructure, are the core problem. Although buying channels share services and data, their planning and optimization logic is repeatedly reimplemented across channels and surfaces, causing drift and technical debt. The proposed solution is a shared agentic decision layer that interprets advertiser goals, orchestrates existing Ads APIs, and applies consistent reasoning across products. ## Fragmented Workflows Across a Shared Backend - Direct, Self-Serve, and Programmatic buying use largely consolidated infrastructure but retain different workflows and decision logic. - Spotify Ads Manager, Salesforce, Slack, and internal tools contain overlapping automation. - Budget allocation, inventory selection, reach, efficiency, and STR decisions are repeatedly implemented in different places. - Incremental workflow changes therefore create duplicated maintenance work and inconsistent behavior. ## Why Conventional Workflow Services Fall Short - Hard-coded state machines and REST services are poorly suited to combinatorial planning tasks. - Campaign planning depends on: - User and advertiser characteristics - Available inventory and audiences - Business priorities - Forecasts, performance, and optimization goals - A workflow optimized for one channel or “happy path” will not adapt well as requirements change. - Improvements to decision logic must be replicated across every product surface, increasing the risk of divergence. ## The Missing Intent Layer - Existing systems can perform individual actions such as creating line items, running forecasts, and retrieving insights. - They do not consistently translate high-level objectives into: - A sequence of tool calls - Explicit tradeoffs - Validation and safety checks - An objective such as maximizing reach in Brazil while protecting video inventory and meeting STR requires coordinated reasoning across multiple capabilities. ## A Modular Agentic Architecture - Campaign planning and management are modeled as cooperating specialized agents. - Agents use shared signals, including: - Inventory - Audiences - STR - Quality and risk - Historical performance - They jointly optimize advertiser goals and Spotify’s business constraints. - Existing Ads services become tools that agents orchestrate, rather than capabilities being rebuilt in each workflow. - A long-running orchestration layer delegates tasks while agents share context and evaluation logic. - The same decision engine can support every buying channel and surface. ## Engineering Implications - APIs need to be designed as agent tools, rather than only as CRUD interfaces. - Testing must include behavioral evaluation in addition to unit and integration tests. - Observability should explain what an agent decided and why, not merely track latency and errors. - Safety requires guardrails for semi-autonomous decisions, beyond ordinary input validation. - The approach avoids both duplicated deterministic workflows and a brittle, centralized rules engine for probabilistic, ML-heavy advertising logic. The overall recommendation is to centralize campaign decision-making in a reusable agentic platform while keeping existing services as specialized tools. This should reduce duplicated workflow logic, make improvements consistent across products, and allow advertising workflows to evolve without repeatedly rebuilding them.

Read original(opens in new tab)
google3 min readCurated summary

Towards a science of scaling agent systems: When and why agent systems work

AI agent systems do not improve simply by adding more agents. Google Research’s evaluation of 180 configurations found that coordination helps substantially on parallelizable tasks but can severely hurt sequential workflows and tool-heavy tasks. The study proposes measurable design principles and a predictive model that selected the best architecture for 87% of unseen tasks. ## Defining Agentic Tasks The study distinguishes agentic tasks from static benchmarks by requiring: - Sustained, multi-step interaction with an external environment. - Iterative information gathering under partial observability. - Adaptive strategy changes based on environmental feedback. Researchers tested five architectures across Finance-Agent, BrowseComp-Plus, PlanCraft, and Workbench: - **Single-agent:** One agent handles reasoning and actions sequentially. - **Independent:** Agents work in parallel without communication and combine results at the end. - **Centralized:** An orchestrator delegates work and synthesizes outputs. - **Decentralized:** Agents communicate directly in a peer-to-peer network. - **Hybrid:** Hierarchical oversight is combined with peer coordination. ## Coordination Must Match the Task - Multi-agent systems produced very different results across GPT, Gemini, and Claude models. - On parallelizable financial reasoning tasks, centralized coordination improved performance by **80.9%** over a single agent. - Parallel agents can independently analyze areas such as revenue, costs, and market comparisons before combining their findings. - On sequential planning tasks, every multi-agent architecture performed worse, with declines of **39–70%**. - Communication and synchronization overhead can fragment reasoning and consume the available cognitive budget. ## The Tool-Coordination Trade-off - As tasks require more tools, coordinating multiple agents becomes increasingly expensive. - Tool-heavy systems, such as coding agents with access to 16 or more tools, face a disproportionate coordination “tax.” - Adding agents is therefore especially risky when actions must be tightly ordered or frequently synchronized. ## Architecture and Reliability - Architecture affects not only performance but also how errors spread. - Independent agents amplified errors by up to **17.2×**, because no mechanism checked their intermediate results. - Centralized systems limited error amplification to **4.4×**. - An orchestrator acts as a validation bottleneck, detecting and containing mistakes before they propagate. ## Predicting the Best Architecture - The researchers built a predictive model using properties such as task decomposability and tool count. - The model achieved an **R² of 0.513**. - It correctly predicted the optimal coordination strategy for **87% of unseen task configurations**. - These results point toward systematic, task-driven agent design rather than relying on the assumption that more agents are always better. For practical deployments, choose architecture based on the task: use coordinated parallel agents for decomposable work, simpler sequential systems for tightly ordered reasoning, and centralized oversight when reliability and error containment are priorities.

Read original(opens in new tab)
googleOriginal article

How we are building the personal health coach (opens in new tab)

Google is leveraging Gemini models to create a proactive, adaptive personal health coach designed to bridge the gap between fragmented health data and actionable wellness guidance. By integrating physiological metrics with behavioral science, the system provides tailored insights and sustainable habit-building plans through a sophisticated multi-agent AI architecture. This initiative, currently in public preview for Fitbit Premium users, represents a transition toward data-driven, expert-validated health coaching that evolves dynamically with an individual's progress. ## Architecting a Multi-Agent Health Coach The system utilizes a complex multi-agent framework to coordinate different specialized AI sub-agents, ensuring that health recommendations are holistic and contextually aware. * **Conversational Agent:** Manages multi-turn interactions, understands user intent, and orchestrates the other agents while gathering necessary context for response generation. * **Data Science Agent:** Employs code-generation capabilities to iteratively fetch, analyze, and summarize physiological time-series data, such as sleep patterns and workout intensity. * **Domain Expert Agent:** Analyzes user data through the lens of specific fields like fitness or nutrition to generate and adapt personalized plans based on changing user context. * **Numerical Reasoning:** The coach performs sophisticated reasoning on health metrics, comparing current data against personal baselines and population-level statistics using capabilities derived from PH-LLM research. ## Ensuring Reliability via the SHARP Framework To move beyond general-purpose AI capabilities, the system is grounded in established coaching frameworks and subjected to rigorous technical and clinical validation. * **SHARP Evaluation:** The model is continuously assessed across five dimensions: Safety, Helpfulness, Accuracy, Relevance, and Personalization. * **Human-in-the-Loop Validation:** The development process involved over 1 million human annotations and 100,000 hours of evaluation by specialists in fields such as cardiology, endocrinology, and behavioral science. * **Expert Oversight:** Google convened a Consumer Health Advisory Panel and collaborated with professional fitness coaches to ensure the AI's recommendations align with real-world professional standards. * **Scientific Grounding:** The coach utilizes novel methods to foster consensus in nuanced health areas, ensuring that wellness recommendations remain scientifically accurate through the use of scaled "autoraters." Eligible Fitbit Premium users on Android in the US can now opt into the public preview to provide feedback on these personalized insights. As the tool evolves through iterative design and user research, it aims to provide a seamless connection between raw health metrics and sustainable lifestyle changes.

googleOriginal article

The anatomy of a personal health agent (opens in new tab)

Google researchers have developed the Personal Health Agent (PHA), an LLM-powered prototype designed to provide evidence-based, personalized health insights by analyzing multimodal data from wearables and blood biomarkers. By utilizing a specialized multi-agent architecture, the system deconstructs complex health queries into specific tasks to ensure statistical accuracy and clinical grounding. The study demonstrates that this modular approach significantly outperforms standard large language models in providing reliable, data-driven wellness support. ## Multi-Agent System Architecture * The PHA framework adopts a "team-based" approach, utilizing three specialist sub-agents: a Data Science agent, a Domain Expert agent, and a Health Coach. * The system was validated using a real-world dataset from 1,200 participants, featuring longitudinal Fitbit data, health questionnaires, and clinical blood test results. * This architecture was designed after a user-centered study of 1,300 health queries, identifying four key needs: general knowledge, data interpretation, wellness advice, and symptom assessment. * Evaluation involved over 1,100 hours of human expert effort across 10 benchmark tasks to ensure the system outperformed base models like Gemini. ## The Data Science Agent * This agent specializes in "contextualized numerical insights," transforming ambiguous queries (e.g., "How is my fitness trending?") into formal statistical analysis plans. * It operates through a two-stage process: first interpreting the user's intent and data sufficiency, then generating executable code to analyze time-series data. * In benchmark testing, the agent achieved a 75.6% score in analysis planning, significantly higher than the 53.7% score achieved by the base model. * The agent's code generation was validated against 173 rigorous unit tests written by human data scientists to ensure accuracy in handling wearable sensor data. ## The Domain Expert Agent * Designed for high-stakes medical accuracy, this agent functions as a grounded source of health knowledge using a multi-step reasoning framework. * It utilizes a "toolbox" approach, granting the LLM access to authoritative external databases such as the National Center for Biotechnology Information (NCBI) to provide verifiable facts. * The agent is specifically tuned to tailor information to the user’s unique profile, including specific biomarkers and pre-existing medical conditions. * Performance was measured through board certification and coaching exam questions, as well as its ability to provide accurate differential diagnoses compared to human clinicians. While currently a research framework rather than a public product, the PHA demonstrates that a modular, specialist-driven AI architecture is essential for safe and effective personal health management. Developers of future health-tech tools should prioritize grounding LLMs in external clinical databases and implementing rigorous statistical validation stages to move beyond the limitations of general-purpose chatbots.