What if you could run multiple coding agents, keep their terminals alive, catch risky actions, and coordinate their work without spending your entire day watching terminal windows?

Running one coding agent is straightforward. Running several agents simultaneously creates a different problem: attention.

One agent is editing a project. Another is waiting for input. A third is producing a wall of terminal output. Somewhere, an agent might be asking for permission to perform a consequential action. Meanwhile, the developer is switching between terminals, reconstructing context, and trying to determine which agent needs attention next.

The problem isn't necessarily that coding agents can't do useful work. It's that supervising multiple agents can become a job of its own.

That's the problem our team wanted to tackle with Bedrock.

Bedrock is an open-source, local-first control plane for running, observing, coordinating, and supervising multiple coding agents through persistent terminal sessions, structured runtimes, AI-assisted monitoring, and explicit human approval gates.

Instead of treating agents as independent chat windows, Bedrock brings their execution, status, shared context, and approval workflows into one place.

Our central design principle is simple:

Let agents handle repetitive work, let software handle repetitive supervision, and keep humans in control of consequential decisions.

This is our submission for the Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

What We Built

The problem: More agents can mean more supervision

Coding agents are useful, but supervising several of them introduces a collection of small, repetitive tasks.

Developers need to switch between terminal windows, read output to determine whether an agent is progressing or blocked, notice permission prompts, inspect potentially destructive commands, relay context, and reconstruct what happened after a UI interruption.

These tasks compete for attention. We wanted to explore a different approach: instead of hiding execution behind another chat interface, what if developers had a control room for the actual agent processes?

That became the core idea behind Bedrock.

1. One control room for multiple coding agents

Bedrock provides a unified project and agent console where developers can manage projects, start agent sessions, inspect output, monitor status, and access coordination features.

Rather than manually juggling unrelated terminal windows, developers can work through a shared interface while retaining access to real interactive terminal sessions through PTY-based execution.

Relevant implementation:

• src/cli-registry.ts
• src/daemon/runtime.ts
• src/pty-manager.ts
• client/src/App.tsx

2. A persistent daemon

One architectural decision we consider important is separating the web server from the process-owning daemon.

The web server handles browser-facing requests and communication. The daemon owns agent lifecycles, runtime coordination, watchers, and related state.

This means restarting the web server does not inherently require terminating the agent processes owned by the daemon. Terminal output is also buffered so a browser can reconnect and receive previously captured output.

Relevant implementation:

• src/server.ts
• src/daemon/daemon.ts
• src/daemon/protocol.ts
• ARCHITECTURE.md

3. Two layers of supervision

Bedrock combines deterministic checks with AI-assisted classification.

The fast path checks normalized terminal output against known patterns for potentially dangerous commands and interactive prompts. The slower Supervisor path processes batches of output to classify events, summarize progress, and identify questions, blockers, or risky actions.

This lets the system detect known patterns without waiting for a model response while retaining contextual analysis for more complex output.

These mechanisms are not a complete sandbox. Pattern matching can miss harmful actions, and model classifications can be wrong.

Relevant implementation:

• src/strands/watcher.ts
• src/gatePatterns.ts
• src/strands/agent.ts

4. Human-approved action proposals

We wanted to preserve a clear distinction between an AI system proposing work and an AI system authorizing work.

The Supervisor can create a pending plan. The application presents that proposal to the human, who can approve or reject it. Only an approved plan proceeds through the plan-resolution path to agent injection.

The decision is recorded in the audit trail.

Relevant implementation:

• src/strands/tools.ts
• src/routes.ts

5. Shared context and coordination

Bedrock includes shared files, a Markdown wiki, project memory, skills discovery, activity logs, Group Chat, and MCP-based messaging for supported agent workflows.

These capabilities are intended to reduce repeated context reconstruction and manual message relay. Support and status reporting can vary between agent integrations.

Relevant implementation:

• src/mcp-server.ts
• src/memory.ts
• src/skills.ts
• src/storage.ts

6. Desktop application

Bedrock also includes an Electron desktop shell and electron-builder packaging configuration.

This provides a desktop distribution path alongside the web interface. The existence of packaging configuration does not, by itself, establish that downloadable release artifacts are currently published for every operating system.

Explore the GitHub Releases page for the current release status and available downloads.

Demo

The strongest demonstration of Bedrock is a real agent workflow: launch a configured agent, inspect its terminal output, demonstrate a reviewable risky-action gate in a disposable workspace, and show the human decision and audit trail.

A second useful demonstration is restarting the web server and reconnecting to the daemon to illustrate the separation between the UI and the process owner.

Live demo: [https://bedrock-site.vercel.app/]

Video walkthrough: [Insert the final Bedrock video]

Any static preview should be identified as sample data rather than presented as proof of live agent execution.

Code

Repository: https://github.com/puneetnith28/Bedrock

Bedrock is licensed under Apache-2.0. The repository includes the application, runtime integrations, supervision logic, documentation, testing scripts, and development workflows.

Useful starting points:

• Architecture
• Testing guide
• Security documentation
• Contribution guide

How We Built It

Our implementation combines a TypeScript application server, a React/Vite interface, a persistent Node.js daemon, runtime adapters, an AI-assisted Supervisor, and an Electron desktop shell.

We used different runtime paths because coding agents do not all expose the same interfaces. Some are managed through interactive PTYs, while others use structured interfaces such as Codex's app-server or ACP-based local model sessions.

We also separated deterministic checks from model-based supervision. Known patterns can be evaluated locally, while contextual classification and summarization can use a configured model provider.

The project uses the Strands Agents SDK for its Supervisor, MCP for supported agent-tool and messaging workflows, and ACP for the LocalHarness runtime. It supports local OpenAI-compatible model servers and has configured paths for open-weight models such as GPT-OSS and Nemotron through aider and hosted providers.

These paths have different requirements. Bedrock does not bundle model weights, and support for local inference does not mean every feature runs offline by default.

We also built explicit approval paths for risky terminal interactions and Supervisor-generated plans. The goal is to keep important decisions visible and reviewable instead of assuming that every model-generated instruction should be executed automatically.

Why Does Open Innovation Matter?

Open innovation matters because Bedrock sits between developers, coding agents, model providers, and the actions those agents can perform.

Developers can inspect the runtime router, gate patterns, approval flow, Supervisor tools, and persistence mechanisms. They can adapt the model layer, experiment with compatible local models, extend runtime integrations, and contribute new safety checks.

The project's value is not simply that its code is public. Its architecture exposes meaningful extension points for investigating how heterogeneous coding agents can be supervised through a shared interface.

Open development also makes limitations visible. Contributors can challenge assumptions, reproduce problems, improve tests, and strengthen the safety mechanisms.

We are not claiming established external adoption or measured productivity gains. Our goal is to make the implementation understandable and extensible enough for other developers to evaluate and improve it.

The Lazy Payoff

Bedrock is designed to reduce repetitive supervision rather than remove human judgment.

We have not established a defensible number of minutes saved or a percentage improvement. We would rather measure that than invent a productivity claim.

A reproducible experiment could compare three agents running in separate terminals against the same agents managed through Bedrock, measuring window switches, time to notice blocked agents, time spent reading output, approval latency, and total human supervision time over repeated runs.

For now, the honest claim is that Bedrock centralizes supervision and automates selected routine steps. The size of the productivity improvement remains to be measured.

Limitations and What We Want to Improve

We want Bedrock's limitations to be visible, too.

• Pattern-based gates are not a complete sandbox.
• The security documentation identifies limitations in the local daemon interface that need careful consideration before using the application with untrusted agents or on shared machines.
• Hosted model and voice workflows may require credentials, provider availability, and quotas.
• Runtime capabilities and status reporting vary across agent implementations.
• Desktop packaging configuration does not prove every platform artifact has been published and verified.
• Productivity gains have not yet been quantified.

These are important areas for further engineering, testing, and contribution.

What's Next?

Our priorities include strengthening reproducible local-model demonstrations, improving the security boundaries around daemon operations, measuring the effort saved during multi-agent work, and making setup easier for new contributors.

We want to make working with multiple coding agents more manageable while keeping their actions observable and consequential decisions reviewable.

If you work on agent runtimes, local models, developer tooling, or AI supervision, we would welcome your feedback and contributions.

Explore Bedrock: https://github.com/puneetnith28/Bedrock

Team

Built by:

• Puneet Yadav — @puneetnith28
• Prashant Bahuguna — dev_prashant_08f09e5e8c7b

Replace the placeholders with the teammate's real name and DEV username before publishing, and describe each person's contributions accurately.

Prize Categories

Primary entry: Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady, subject to confirmation of the challenge's new-project eligibility requirements.

We are focusing on the overall challenge rather than claiming partner categories without evidence of the required integrations.

Built in the spirit of open innovation: make the system inspectable, keep humans in the loop, and leave room for others to improve it.

AI #devchallenge #hf26challenge