1
Request
Back to all projects
Architecture Note
Multi-Agent Workbench
A static architecture note showing how agent, browser, relay, and server layers are separated, where human confirmation is required, and why no executable demo is public.
Architecture Note · Non-executable public treatment
All applied AI projectsCase only · No executable demo
RoleEnterprise-adaptation contributor
StatusArchitecture Note · Non-executable public treatment
A static architecture note showing how agent, browser, relay, and server layers are separated, where human confirmation is required, and why no executable demo is public.
- Target user
- Platform, security, and release reviewers
- Input
- Public-safe architecture facts and non-release constraints
- Output
- Static architecture and non-release rationale
- Public format
- Architecture Note
Public case
Use the case, then inspect the decision trail.
The case uses fictional, synthetic, or prepared material. It shows only the parts that can be released safely. The internal runtime is not public.
Architecture note
How the workbench limits browser and agent actions.
2
Orchestration
Agent work plan
Specialized workers receive defined subtasks and return their results.3
Browser boundary
Isolated execution
A relay separates the planning layer from an authenticated browser session.4
Decision gate
Human confirmation
Material, irreversible, or externally visible actions require explicit approval.5
Record
Outcome and trace
The result, exception, and decision are recorded for review.Contribution boundary
Enterprise adaptation, not a solo greenfield build.
The original internal pilot was co-developed. The public Portfolio describes product decisions and confirmation controls without assigning every component or commit to one person.
Upstream attribution
Adapted from Apache Codeg foundations.
The upstream base is credited explicitly. No upstream or internal source, browser relay, session, logged-in site, or real execution command is distributed here.
Problem
The user problem
A server-hosted agent/browser workbench needs explicit boundaries for logged-in sessions, browser relay, and dangerous actions before any release decision.
Workflow
Steps from input to decision
- Separate agent, browser, relay, and server layers
- Identify logged-in and session-data boundaries
- Place dangerous actions behind explicit confirmation
- Document why an executable public demo is not released
Validation
What was checked
- Confirmation gates and prohibited public surfaces are explicit
- Apache Codeg upstream attribution and multi-contributor boundaries remain visible
Evidence
What the case verifies
- The public-safe evidence is a static architecture note covering the problem, agent/browser layers, confirmation gates, contribution boundary, and non-release rationale.
- Dangerous actions remain subject to explicit confirmation in the documented design.
Continue