[{"slug":"mission","title":"Mission","summary":"Why we started Coastal Digital Research and what we're working on.","tags":["mission","values","vision"],"content_md":"## Mission\n\nWe build open-source infrastructure for AI agents. Tools, runtimes, protocols, the unglamorous stuff that runs underneath the model and decides whether the model can actually do anything useful.\n\nThat's where most of the interesting work is right now. Agents need to read files, run commands, cache results, remember things between sessions, and stay within their authorized scope. Each one of those is a real engineering problem with real consequences when it breaks, and most of them aren't going to be solved by training a bigger model. They get solved by people writing careful infrastructure code. We'd rather be those people than ship another model wrapper.\n\n## Vision\n\nAgents deployed with the same care we apply to databases. We should be able to see what an agent did, audit why it did it, and roll back when something breaks. That's table stakes for software that touches real money, real systems, and real decisions. Today most agent infrastructure is closer to a demo than a system. We want to close that gap.\n\n## Values\n\n**Open by default.** Code is public. Manifests are public. Agent behavior is inspectable. If you can't see how something works, you can't trust it, and trust matters more for agents than for almost any other class of software.\n\n**Correctness over speed.** We'd rather ship one thing that works than five that mostly work. AI infrastructure that misbehaves isn't a bug, it's a governance failure. The blast radius for a misbehaving agent is bigger than people give it credit for.\n\n**Human legibility.** Logs should read like English. APIs should explain themselves. A system that a person can't audit doesn't deserve to run unattended, no matter how impressive the model behind it.\n\n**Minimal footprint.** Agents get the smallest set of permissions and tools that get the job done. Anything more is a future incident waiting to happen. The right question is never \"what should this agent be able to do?\" It's \"what's the smallest thing this agent can do and still finish its task?\"\n\n## What We Don't Do\n\nWe don't train foundation models. We don't sell hosted inference. We work on the layer above, which is the runtime, the memory, and the protocols that let models actually do useful work without breaking things.\n\nAgents aren't chatbots. They're infrastructure. We want to build them like infrastructure."},{"slug":"policies","title":"Policies","summary":"Open source, data, and governance policies.","tags":["policy","governance","open-source","data"],"content_md":"## Open Source Policy\n\nAll CDR software is Apache License 2.0 unless explicitly noted. The license allows commercial use, requires attribution, and includes a patent grant. We chose it for all three reasons. The patent grant is the part most people overlook, and it's the part that matters most as soon as anything you build starts touching real customers.\n\nContributors keep copyright on what they wrote. Opening a pull request means you're agreeing your work can be distributed under the project's license. We don't ask for CLAs.\n\nWe don't dual-license. We don't sell closed versions of the open-source tools. If you see a CDR repository, what's there is what we build with too.\n\n## Data Policy\n\nThis site doesn't collect user data beyond standard server access logs. Logs are kept for 30 days. They're not shared with third parties.\n\nAgent manifests contain only what's declared in the YAML. No telemetry is embedded.\n\nCDRcache stores content hashes and agent outputs. No PII should ever go in there, and we treat that as a hard rule, not a guideline. Cache entries are content-addressed and immutable once written, so a leak would be permanent. Better to not let it happen in the first place.\n\n## Governance Policy\n\nDecisions on project direction, releases, and governance are made by the CDR maintainers. We're small enough that this is a sentence, not a chart.\n\nExternal contributions via pull request are welcome. Correctness, documentation, and test coverage improvements get prioritized. Anything that increases attack surface needs a security review before we'll merge it, even if the code itself looks fine.\n\nSecurity issues should go through GitHub's private vulnerability reporting on the affected repo. We aim to respond inside 72 hours. We'll write up disclosed issues publicly once they're fixed; we don't sit on them.\n\n## Agent Behavior Policy\n\nAgents we operate:\n\n- Act only on tasks they were explicitly authorized to do\n- Log enough detail to reconstruct what happened\n- Don't store credentials or secrets in plaintext\n- Don't reach out to domains that aren't in their manifest\n- Respect rate limits and terms of service for any external service they touch\n\nManifests are public. If CDR is running an agent, its capabilities, entrypoint, and runtime show up in the registry at /agents. If an agent isn't listed there, we aren't running it."},{"slug":"projects","title":"Projects","summary":"Open-source repos we maintain under Coastal Digital Research.","tags":["projects","open-source","repos"],"content_md":"Most of what we work on falls into three buckets: agent tools and runtimes that people actually use, infrastructure that other agents run on top of, and model-architecture research where we're trying things that the bigger labs aren't. Everything below is Apache-2.0 unless noted.\n\n## Agent Tools and Runtimes\n\n### mae\n\nMinimal Agentic Environment. mae is an AI agent that runs on a Linux box and keeps it healthy. It applies updates, enforces configuration, hardens security, and executes whatever tasks you hand it through a web UI. The idea is that most Linux maintenance is repetitive enough that a properly scoped agent can take it over, freeing the human to focus on the actual work. Multi-provider: works with Claude, OpenAI, OpenRouter, OpenCode Zen, or fully local models via Ollama. Originally forked from VibeOS and rebuilt to fit how we think about agent-managed systems.\n\nRepository: github.com/CoastalDigitalResearch/mae\n\n---\n\n### rlm-linux\n\nA self-hosted, recursive-orchestration assistant for Fedora-based Linux. rlm-linux does two things. First, it composes a custom Fedora image: package set, kickstart, systemd services, desktop environment, dotfiles. Second, once installed, it becomes the resident customization layer on the system, orchestrating upgrades, config drift, log triage, RPM authoring, and the lifecycle of isolated AI project sandboxes. Internally it uses a small 7B conductor model that emits agentic workflows in natural language, executed against a tiered worker pool. Still early.\n\nRepository: github.com/CoastalDigitalResearch/rlm-linux\n\n---\n\n### Pachyterm\n\nA cross-platform, GPU-accelerated terminal emulator with native AI agent integration, built in Rust. Sub-50ms time-to-first-frame. Type `p` at the beginning of a line to turn the rest into an LLM prompt. POSIX compliant so it actually works with every shell and TUI you already use. Supports local GGUF/MLC/vLLM models with remote fallback. We built this because the terminal landscape forces you to choose between fast (Alacritty-class) and AI-aware (Warp), and there's no real reason that should be true.\n\nRepository: github.com/CoastalDigitalResearch/Pachyterm\n\n---\n\n### CDRbrowser\n\nA 100% AI-built and AI-maintained web browser. Not a Chromium fork. Not a Firefox fork. A clean-slate Rust web engine paired with a native AI synthesis plane: video summaries, audio briefings, source collation, agentic browsing. The architecture leans on a Rust HTML5 parser, CSS layout, wgpu compositor, QuickJS++ JS engine, and HTTP/2/3, with capability-based sandboxing and per-site WASM containers. The synthesis side runs MCP/A2A orchestration over multimodal pipelines. Whether browsers should be built this way is an open question. We wanted to find out.\n\nRepository: github.com/CoastalDigitalResearch/CDRbrowser\n\n---\n\n### cdr-home\n\nThis site. A FastAPI app that serves the same content as HTML for humans and as JSON or Markdown for agents. Reference implementation for the dual-mode approach: human pages and agent endpoints sharing the same source of truth, with proper content negotiation so each kind of visitor gets what they actually want.\n\nRepository: github.com/CoastalDigitalResearch/cdr-home\n\n---\n\n## Agent Infrastructure\n\n### Orchestack\n\nAn orchestration platform for agent systems. Designed to handle hundreds of concurrent agent sessions with sub-500ms response latency, with multi-tenancy via namespace isolation, RBAC and network policies, optional air-gapped deployments, and per-workspace ownership. Includes Discord and Telegram connectors, subagent spawning, file and memory tools, web search and fetch, remote node execution, and cron scheduling. Built for internal operators first; multi-tenant SaaS is a v2 concern.\n\nRepository: github.com/CoastalDigitalResearch/Orchestack\n\n---\n\n### CDRcache\n\nKnowledge caching layer for agent systems. A semantic caching and retrieval system designed for AI agent pipelines. The reason caching matters here isn't just speed: if an agent's output is a deterministic function of its inputs, you only want to run it once, and the cache becomes a stable audit trail of what was produced and when. The audit trail is the part we care about most.\n\nRepository: github.com/CoastalDigitalResearch/CDRcache\n\n---\n\n## Model Architecture Research\n\n### TopoLI\n\nTopological Late Interaction. A ColBERTv2 variant that uses persistent homology from topological data analysis to prune token embeddings for efficient retrieval. ColBERT-style models store documents as bags of token embeddings, which works well but eats storage. TopoLI asks which tokens actually matter for retrieval and keeps only those, identifying bridge tokens that connect semantic clusters and boundary tokens that form topological cycles. Result: fewer stored tokens with minimal retrieval-quality loss.\n\nRepository: github.com/CoastalDigitalResearch/TopoLI\n\n---\n\n### fpre\n\nFirst Principles Reasoning Engine. Neural-guided hybrid reasoning with typed primitives, built as a Rust core with Python orchestration. The premise is that pure LLM \"reasoning\" hits a ceiling on problems that need real symbolic structure, and the right architecture is a tight loop between a model that proposes and a typed engine that verifies. Still early.\n\nRepository: github.com/CoastalDigitalResearch/fpre\n\n---\n\n### CDRmem\n\nResearch and implementation of architectural memory patterns for language models. Memory access gates and fast-weight memory architecture, including taxonomy-routed retrieval, fast-weight episodic memory modules, and deterministic memory gating. Designed for dynamic, auditable, and updatable knowledge access. Less about storing vectors and more about how a model accesses what it remembers.\n\nRepository: github.com/CoastalDigitalResearch/CDRmem\n\n---\n\n### CDRdistill\n\nH-neuron detection for hallucination-aware model distillation. A hybrid distillation framework that uses H-subspace (hallucination neuron) detection to guide the distillation process, producing smaller models that are measurably more grounded and less prone to hallucination. The interesting bit is treating hallucination as something locatable in the network rather than as a black-box behavior.\n\nRepository: github.com/CoastalDigitalResearch/CDRdistill\n\n---"},{"slug":"research","title":"Research","summary":"What we're thinking about and writing about.","tags":["research","AI","infrastructure","agents"],"content_md":"## Research Focus\n\nThe work here is applied. We study the problems we hit while building and running agents, then we write up what we learn. Less paper-style research, more field notes. The questions that interest us are the ones that come back every week, in different shapes, in different projects.\n\n## Agent Runtime Design\n\nWhat's the right shape for an agent as a software component? Stateless agents are easier to reason about and easier to scale. Stateful agents do more interesting work but are harder to audit. There's no universal answer, but the tradeoff shows up every time, and most projects pick badly on the first pass and pay for it later. The agent manifests on this site try to make the tradeoff explicit by declaring the fields that actually matter: entrypoint, runtime, tools, inputs, outputs, SLOs.\n\nThe piece we keep coming back to is failure handling. When does an agent retry? When does it escalate? When does it stop and wait for a human? Most agent frameworks don't take this seriously enough, which is wild given that \"what to do when you're confused\" is roughly the whole point of having an agent.\n\n## Content-Addressed Agent Memory\n\nCDRcache is the experiment here. If an agent's output is a deterministic function of its inputs, that output can be hashed and stored. You skip the rerun next time, and you get an audit trail for free. That's a pretty good deal if you can pull it off.\n\nThe open questions are the ones you'd expect. What about agents that aren't fully deterministic, which is most of them? How do you invalidate cache entries when the underlying model or tool changes? When is the audit trail more valuable than the cache hit, and when is it the other way around? We don't have clean answers yet. We have working code and a growing list of cases where caching helped and a smaller list of cases where it hurt.\n\n## Dual-Mode Web Infrastructure\n\nMost websites are designed for humans. Agents browsing those sites have to parse around navigation chrome, ads, and layout to get to the content. That's slow, expensive in tokens, and error-prone. The fix is to serve the same content twice, in different shapes: HTML for people, JSON or Markdown for machines, with content negotiation so each visitor gets what they actually want.\n\nThis site is the implementation we keep iterating on. The `/.well-known/agent.json` convention is one half of the story. Content negotiation is the other. Neither is novel by itself. The interesting part is making both work in one codebase without compromise to either side.\n\n## Minimal Agent Footprint\n\nWhat's the smallest set of capabilities an agent needs to do its job? Permissions should be tight enough that an agent can't take an action it wasn't authorized for. Catching mistakes after the fact isn't enough, especially when the mistakes involve writing to a database or talking to a customer or moving money.\n\nThis is mostly an interface design problem. If your API makes the dangerous action just as easy as the safe action, agents will sometimes take the dangerous one. If the dangerous action requires extra ceremony, they mostly won't. We're interested in what that ceremony looks like in practice.\n\n## Observability for AI Systems\n\nLogs, metrics, and traces were built for deterministic software, where the same input produces the same output and you can replay a failure with confidence. Agent behavior is emergent. Context windows are large. The usual tooling doesn't quite fit.\n\nWe're working through what to log, at what granularity, and how to structure it so both a person reviewing an incident and another agent doing analysis can use it. The answer probably isn't \"more logs.\" It's logs designed for the specific failure modes that agents have, which aren't the failure modes traditional services have."},{"slug":"workflows","title":"Workflows","summary":"How CDR actually runs.","tags":["workflows","operations","process"],"content_md":"## How CDR Works\n\nSmall and asynchronous. Most work happens in code and in agent task logs, not in meetings. The whole point of building agent infrastructure is that you should be able to coordinate work without sitting on calls all day, so we try to live that as much as we can.\n\n## Development Workflow\n\n**Trunk-based.** One main branch per repo. Short-lived feature branches. No long-lived branches sitting around collecting conflicts.\n\n**Commit hygiene.** Each commit should be one coherent change with a message that says why. Typos and formatting get squashed before merge. The git history is the audit trail, so it has to actually be readable.\n\n**Tests before ship.** Nothing merges without tests passing. Infrastructure pieces get integration tests against realistic environments, not just unit tests. Mocked tests catch the easy cases but miss the bugs that actually take production down.\n\n**Agents in the loop.** We use our own agents for the work we can hand off. mae does file edits and code searches. CDRbrowser handles web research. CDRcache memoizes intermediate steps in long pipelines. If we're not eating our own dog food, we don't really understand what we're building.\n\n## Release Workflow\n\nSemantic versioning. We cut a release when:\n\n1. Tests pass on main.\n2. The changelog is current.\n3. The container image builds cleanly.\n4. The agent manifest, if there is one, reflects the new version.\n\nReleases are tagged in git and published as container images where it makes sense. Nothing exotic.\n\n## Incident Workflow\n\nWhen an agent misbehaves or a service goes down:\n\n1. Figure out the blast radius. What was affected, for how long, what's at risk.\n2. Contain it. Disable the agent. Roll back to the last known good state.\n3. Read the logs and reconstruct what happened.\n4. Write a short incident note in the repo's incident log.\n5. Fix the root cause before turning anything back on.\n\nThe order matters. Containment before forensics. Forensics before fix. Fix before restart. Most agent incidents we've seen got worse because someone skipped a step.\n\n## Communication\n\nGitHub issues and discussions on the relevant repo. No Slack, no Discord, no mailing list. If you need to reach us about a project, open an issue. We respond faster to a clearly written issue than to a chat ping, every time."}]