DEV Community: Puneet Yadav

Bedrock: The Human-in-the-Loop Control Room for Coding Agents

Puneet Yadav — Sun, 25 Oct 2026 18:29:06 +0000

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:

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:

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:

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:

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:

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: https://youtu.be/VkWTsyLh7dI

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:

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.

Manual work	Intended Bedrock benefit
Switching between terminal windows	Consolidated access to agent sessions
Reading repetitive output	Activity views and Supervisor summaries
Relaying context between agents	Shared project content and supported MCP messaging
Reconstructing context after UI interruptions	Daemon-owned processes and buffered output
Answering every routine prompt	Configurable handling for eligible routine prompts
Rebuilding project knowledge	Wiki, memory, skills, and shared files
Reconstructing past decisions	Activity and audit records

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

Parakh: AI-Powered Developer Capability Assessment

Puneet Yadav — Sun, 18 Oct 2026 18:25:23 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Parakh turns developer skill claims into evidence-backed, cryptographically verifiable assessments.

Developers often list frameworks, technologies, and skills on resumes, but evaluating those claims is time-consuming and vulnerable to superficial keyword matching. Recruiters, engineering hiring managers, and evaluators need a reliable way to understand what a developer has actually built and tested.

Parakh addresses this problem by evaluating public GitHub repositories against specific job descriptions or opportunity briefs. Rather than generating ungrounded AI summaries, Parakh connects skill requirements to code citations, including file paths and line ranges, associated with a specific Git commit.

Crucially, Parakh distinguishes between what the evidence demonstrates, what is partially demonstrated, and what is absent. Missing evidence in a repository is not treated as proof that a candidate lacks a skill. Instead, it is reported as Not Demonstrated in Supplied Evidence.

Who benefits from Parakh?

Developers and freelancers: Demonstrate hands-on expertise with code evidence and receive actionable recommendations to strengthen their portfolios.
Recruiters and engineering managers: Explore a more transparent, evidence-oriented approach to technical screening.
Open-source contributors: Highlight architectural patterns, implementation details, and tested components in their repositories.

Demo & Links

🌐 Live Web Application: https://parakh-web.onrender.com
🔌 API Health Probe: https://parakh-api-kyyz.onrender.com/healthz
💻 GitHub Repository: https://github.com/puneetnith28/Parakh
🎥 Demo Video: https://www.youtube.com/watch?v=YJlloKOkdi8

The demo walks through the Parakh interface, the assessment workflow, the evidence map, the action plan, and the system architecture.

How I Built It

Parakh is built as a TypeScript monorepo combining repository analysis, AI-assisted reasoning, structured evidence retrieval, citation validation, and persistent storage.

Core Technology Stack & Integrations

Frontend: React 18 and Vite, with interactive evidence maps, code citation views, and an audio player interface.
Backend: Node.js and Express, with typed assessment orchestration, request validation, and security controls.
Google AI Studio / Gemini: AI-assisted requirement extraction and qualitative evaluation, with structured outputs, rate-limit handling, and deterministic fallbacks.
Google Gemma: Support for open-weight model configurations where the appropriate model is configured and operational.
MongoDB Atlas: Persistent storage for reports and assessment data, with indexing and document lifecycle management.
Sentry: Assessment workflow tracing and privacy-oriented scrubbing of sensitive data.
ElevenLabs: An audio briefing integration with an in-app playback interface and fallback handling.
Render: Hosting for the frontend and backend services.

The Five-Step Assessment Workflow

1. Opportunity Ingestion

Parakh processes job descriptions, client requirements, or opportunity briefs into structured skill requirements.

2. Repository Security and Commit Pinning

The system validates repository URLs, applies security checks, and associates repository evidence with a specific Git commit so that findings can be traced back to a defined code version.

3. Multi-Stage Evidence Retrieval

Repository content is examined using lexical ranking and code-structure extraction to identify potentially relevant functions, classes, and code snippets.

4. Citation Validation

Assessment findings are checked against repository evidence and source locations. The goal is to ensure that conclusions can be traced to relevant files and line ranges instead of relying solely on unsupported AI-generated statements.

5. Report Storage and Verification

Assessment reports are stored persistently. Cryptographic integrity mechanisms and controlled report access are intended to make subsequent verification and sharing more trustworthy.

A core design principle runs throughout the workflow: AI should help interpret evidence, not replace it. When a repository does not demonstrate a particular capability, the assessment should communicate that limitation rather than make an unsupported judgment about the developer.

Why Does Open Innovation Matter?

An application built around evidence, auditability, and fairness should itself be open to inspection.

By developing Parakh in the open under the Apache-2.0 license, the project invites developers and evaluators to inspect its implementation, review its assessment logic, examine citation validation, and contribute improvements.

Open-source development also creates opportunities to challenge assumptions about AI-assisted hiring and technical evaluation. Contributors can investigate how evidence is selected, how uncertainty is communicated, and how assessment workflows can avoid treating an incomplete repository as a complete picture of someone's abilities.

For an AI-powered product, openness matters because people should have an opportunity to question how conclusions are produced instead of simply accepting a black-box score.

Prize Categories

Primary Track

Hacktoberfest Open-Source AI Challenge - Week 2: Side Hustle: An evidence-oriented developer capability assessment platform designed to help connect technical requirements with demonstrated repository work.

Sponsor Prize Tracks

Google AI Studio: Structured AI-assisted reasoning, requirement extraction, rate-limit handling, and support for Gemma configurations where verified.
MongoDB Atlas: Persistent assessment storage, indexing, and report lifecycle management.
Sentry: Assessment workflow tracing and privacy-conscious data handling.
ElevenLabs: Audio briefing generation and an in-app playback interface.
Render: Deployment of the frontend and backend services.

These are the integrations associated with the project. Final eligibility for each sponsor category depends on the official rules and the functionality demonstrated by the submitted code and running application.

Closing Thoughts

Parakh was built on a simple conviction: a skill claim is only as credible as the evidence backing it.

By grounding AI-assisted evaluation in repository evidence, traceable code locations, and structured validation, Parakh explores a more transparent way to connect developer capabilities with opportunities.

The project is an ongoing open-source effort, and there is room to improve evidence coverage, assessment quality, verification, and the contributor experience.

Parakh - Prove your skills. Back every claim.

GitHub: https://github.com/puneetnith28/Parakh
Live Demo: https://parakh-web.onrender.com

Hacktoberfest #OpenSource #AI #Gemini #MongoDB #Sentry #ElevenLabs #Render #DeveloperTools #devchallenge #hf26challenge