待翻譯:Show HN: Pacific Slate: a self-hosted, model-agnostic multi-agent AI assistant
AI 服務暫時不可用,以下為來源摘要,待恢復後補全翻譯:Pacific Slate I was in the first year of an MBA, trying to manage a firehose of information while applying to internships and keeping up with my wife and two kids, and I kept re-explaining my whole situation to whatever…
AI 服務暫時不可用,以下為來源正文,待恢復後補全翻譯。
Pacific Slate I was in the first year of an MBA, trying to manage a firehose of information while applying to internships and keeping up with my wife and two kids, and I kept re-explaining my whole situation to whatever AI program I was using that week. I wanted one that updated itself, filtered the slop, and kept the data mine. It runs on a rented server, a dedicated machine that hosts the services and holds encrypted backups of the files I care about. I designed it, selected the parts, and run it day to day (technical details in the collapsed sections at the bottom). What it does Updates itself from my sources, sorts through the noise, and maintains the data in my privately owned database. Uses a multi-agent tree to route work to the model best suited for it. Remembers my choices and preferences, and learns from past outcomes (applying lessons learned to new tasks or situations). Cites sources and maintains logs of everything it does, allowing for traceability and accountability. Checks the source document rather than trusting what it remembers. Integrates into the tools and services I already use, so it adjusts to my workflow rather than forcing me to change it. What I stopped building I learned quickly to prioritize durability, utility, and productivity over novelty. The system is not a product, and it is not a research project. It is a tool I use every day, and it has to work when I’m not there or don’t have the time to maintain it. I had originally built mobile and desktop clients to reach it, but they were more work than I could comfortably invest. I deleted them and now reach it from the tools (MCP, plugins, hooks) commonplace throughout AI development. It’s been important to futureproof the system, and the design is intentionally service-agnostic so it can flex to whatever is best at the time. How a request is handled Eight agents do the work: one that reads the request and routes it, and seven specialists for research, code, analysis, review, and related work. Each runs on a model chosen for that job, so a short lookup and a long analysis do not draw the same cost or wait on the same machinery. Answers carry their sources, so a claim can be traced, and the cost of the call, so spending stays visible as it happens rather than at the end of the month. The interface The workspace, from the public demo. Answers arrive as cards that can be moved around rather than as one long thread, each labeled with the model used, the cost, and the time taken. Demo: pacslate.com/demo. The real interface on sample data. Canvas. Enter a prompt or watch it run. Open Monitor. A dashboard. Seismic data and headlines are live, fetched in the browser; markets, aircraft, and anything personal are labeled sample data. Open What is mine and what is rented The parts that accumulate stay on my server. The model is rented. The model is the one part I do not control, so it is treated as replaceable. Substituting a better one is a configuration change. What is stored is exportable and deletable, and is not used for training. Requests that go out are restricted to zero-data-retention endpoints, at providers configured not to train on them or publish them (account settings, August 2026). Where nothing should leave the server, work can be pointed at a model running on it. I hold what accumulates, I decide where requests go, and none of it becomes a vendor’s asset. Open source, and what I pay for Almost all of it is open source, assembled and run on my own server rather than rented as a service. Where an open-source equivalent did the job, I switched to it and kept the data. What I still pay for is the model, and one hosted memory service that stays swappable and is not the system of record. Building it While computer science and software engineering have always been intriguing, I didn’t have any background developing code myself. The development of this system has been possible through working in partnership with the numerous tools and services currently available online. The architecture itself has all been created independently: which components exist, how they connect, what each runs on, how it behaves when a part fails, and what it is allowed to ‘spend’ (the budget for each module or platform). I built it AI-natively, specifying and reviewing while coding agents wrote most of the code. It has run since early 2026 and I use it daily. Most of what the technical sections describe came out of operating it rather than planning it. For example, the fallback layer exists because the framework’s own fallback setting turned out to do nothing. Another instance, the model label on every answer exists as a way to backtrace a behavioral regression to a model swap that was invisible in the logs. Most of the issues I hit in production were not bugs but design gaps, and it was only through operating the system that I discovered them. Because I built Pacific Slate while working and going to grad school, my free time (or lack thereof) shaped the design more than anything else. It had to be useful in the hours I wasn’t there: scheduled runs, low-risk dependencies and security updates that merge on their own, and failures that degrade to a working state rather than waiting for me. Technical detail Model names on this page and in the example config are illustrative; the design is model-agnostic and the roster rotates. Counts are current as of August 2026 and were checked against the running system. 1 · Agents and memory · the design, not the assembly A designed multi-agent system, not a chat model with plugins. A multi-agent tree on Google’s Agent Development Kit (ADK): one operator at the root plus seven specialists (coder, researcher, analyst, productivity, reviewer, evaluator, and a research sub-agent scoped to the coder). Cost and fit. Each role maps to the model best suited and priced for its work. Independent review. The evaluator runs on a different model family than the agents whose output it scores. Different weights are not guaranteed different biases, but it beats self-scoring. The reviewer is a separate instance kept off the write path by policy. Least privilege. Tools are scoped per role by explicit allow-list. The researcher cannot reach infrastructure. The reviewer is read-only by charter. The productivity agent’s credentials are isolated, so a failure there cannot take down the operator. Containment. A rate-limit or crash stays inside one specialist. ADK enforces a single-parent constraint on sub-agents, which is why the coder’s research arm is a separate instance from the standalone researcher despite sharing a model and tools. Specialists publish findings to a Redis event stream that peers read as ambient context. Longer asynchronous jobs hand off to a background orchestrator rather than occupying the synchronous path. Model independence. The substrate is exposed two ways: an MCP gateway (tools and memory over the Model Context Protocol, mountable by any MCP-capable client) and an OpenAI-compatible endpoint. Memory, data, tools, routing, and verification do not move when the model does. Memory, in four layers. Layer Function Knowledge corpus ~14,000 documents, ~196,000 passages. Hybrid retrieval: keyword plus vector similarity Continuity graph Links related conversations, decisions, and topics over time Semantic memory Durable facts for cross-session recall, with a nightly reconciliation and de-duplication job Tiered context Always-loaded core kept small; the rest retrieved on demand Two rules govern all of it. A deterministic relevance pass decides what to load before any model runs, with no model call. And recalled memory is treated as a lead rather than a fact: if memory says a vendor renews in July, the agent pulls the source document and acts on that. Proactive jobs. Scheduled routines pull from many sources and score each candidate item for relevance, materiality, and novelty before it can enter a brief. Discarded items are logged rather than dropped silently, so the filter can be audited. A consolidation stage de-duplicates and normalizes before anything is stored, and screens for credentials and personal data on the way in. Operating principles. Algorithm first. Default data access and classification to something deterministic: regex, an index, SQL, set membership. Use a model only for the irreducible part. The complexity scorer, the tool search, and the memory relevance pass are all applications of this. Make failure visible, then cheap. Each reliability fix pairs a guardrail with a trace, so the same class of problem cannot recur unseen. Resilience over peak capability. Where the two conflict, uptime wins. Cost as a design constraint. A real ceiling forces honest choices about model, context size, and when to use a model at all. See: examples/model-routing.example.yaml for the routing structure · the model and cost label on each card in the demo. 2 · Integration · models, tools, data, and interface as one system Model providers, tools, data, memory, and a frontend are integrated into one environment reachable over standard interfaces. Request path: The canvas, a Next.js single-page app, opens a streaming connection and posts the prompt. Streaming uses the AG-UI protocol over Server-Sent Events, so tokens, tool calls, and model-resolution events arrive on one stream. The backend is a Starlette service exposing the AG-UI endpoint for the canvas and an OpenAI-compatible endpoint for other clients. The operator classifies the request and either answers inline or hands off to a specialist. The specialist loads context and calls tools over MCP. The resilient model layer resolves the model for that call, applies cost-aware downgrades and health-aware fallback (section 3), streams the completion, and meters cost. The answer streams back as a card labeled with model and cost. Durable facts are written to memory. Two speed tiers result: inline answers in a single model call, and delegated runs where a specialist works its own tool loop. System diagram. Click to enlarge. Tool layer. About two dozen tool-servers (memory, retrieval, code execution, git, feeds, infrastructure) behind one token-authenticated gateway, FastMCP over streamable HTTP, each server its own process. Register, do not rewire. New capability means registering a server. The cost is an extra hop and a single failure domain at the gateway, which is why the gateway has its own health check and the fleet is health-polled. Search, do not load. Carrying every tool schema in every agent’s context is expensive and dilutes attention, so the gateway exposes a BM25 search over the tool catalog. The MCP specification only lists tools; this search is an addition. Layer Choice Agent framework Google ADK, multi-agent tree Backend Starlette, AG-UI over SSE plus OpenAI-compatible endpoint Frontend Next.js, streaming result cards on a spatial canvas Inter-agent bus Redis event streams Tooling ~24 MCP servers behind one gateway, BM25 tool search Operator long-context model with native tool calling Coder code-specialized model, large context Researcher fast long-context model, single pass Analyst large mixture-of-experts reasoning model Reviewer, evaluator independent of the code-writers, scored on a different model family Memory hybrid-retrieval corpus, continuity graph, semantic memory, tiered context Infrastructure Docker, four segmented network tiers, Cloudflare Tunnel, sandboxed execution Reliability per-role fallback chains, health tracker, first-token watchdog, graceful degrade Cost per-request metering to a monthly ceiling, full call and swap tracing See: the diagram above · the demo, which is the same canvas and protocol running against scripted events. 3 · Reliability and cost · the part that took the most iteration It stays up, stays within budget, and checks its own output, and each of those mechanisms is observable. [truncated for AI cost control]