CASTRA WebMCP Challenge Submission Draft
Inspiration
I’m a chemical engineer with 18 years of experience delivering capital projects in the oil and gas industry. I’m also a non-IT technical business user working in an industry where new technology is often adopted slowly, even when the potential value is clear. Too often, people closest to the business problem can describe exactly what needs to change but must wait for scarce technical resources to turn that knowledge into a working solution.
I started building CASTRA (Command Agentic System for Tactical Readiness & Automation) to show that this gap can be narrowed. Non-technical business leaders should be able to express intent, set priorities, make decisions, and direct agent-built solutions without becoming software engineers or AI specialists. Real transformation will not come from demonstrations alone; it will come from practical examples that solve real problems while earning the trust of the people and organizations expected to use them.
My military background also shaped CASTRA. Effective teams operate from clear Commander’s Intent, execute through decentralized initiative, and use disciplined checks to confirm that the outcome is safe, reliable, and aligned with the mission. CASTRA applies those principles to human-agent collaboration.
What It Does
CASTRA is a human-led command platform for planning, governing, executing, and verifying work performed by specialized AI agents. It turns strategic intent into a visible hierarchy of Campaigns, Missions, and Actions, then carries that work through proposal, approval, execution, evidence, independent review, and closeout.
The Commander remains the authority. Agents can research, draft, build, test, review, and document, but they cannot silently approve their own work or cross protected gates. CASTRA keeps priorities, dependencies, costs, risks, decisions, evidence, and current status visible in one operating environment.
For non-technical users, the goal is simple: provide a familiar interface for directing sophisticated technical work without requiring them to manage code, prompts, model infrastructure, or disconnected agent sessions. CASTRA makes agent activity feel like business work rather than a collection of opaque AI conversations. WebMCP makes it even easier for non-technical users because they can state their intent and their AI co-developer can make adjustments much faster and the user can see the results of their ask. And then they can iterate faster to the end result.
How We Built It
CASTRA was built as a web application with a deterministic workflow core. Routine record operations, status transitions, identifiers, rollups, authority checks, and audit history are handled by code and data rules rather than language-model judgment. Optional AI assistance is deliberately separated from the operational source of truth.
The platform uses a role-based agent team. SARGE orchestrates the work; RECON performs bounded research; FORGE implements nonvisual capabilities; SIGNAL builds the user experience; FIREWATCH independently verifies the result; SCRIBE preserves the record; and Quartermaster measures usage and stewardship. Each role has a defined scope, model/runtime binding, evidence expectations, and stop conditions.
We built CASTRA iteratively using CASTRA itself. Every material improvement is planned as governed work, implemented in a bounded candidate, tested proportionally, independently reviewed, and tied to evidence. The application includes hosted operational state, browser-based command surfaces, deterministic Public Demo isolation, session-continuity packages for cold pickup, and a deployed web interface.
Challenges We Ran Into
The hardest challenge was balancing useful agent autonomy with meaningful human control. Giving an agent access to a tool is easy; proving what it was authorized to do, what inputs it used, what changed, and whether the result can be trusted is much harder.
We also had to solve continuity across long-running, multi-agent work. Sessions end, model limits are reached, providers differ, and work may resume later in another environment. CASTRA therefore needed hash-bound handoffs, explicit authority reads, idempotent operations, reconciliation for unknown outcomes, and fail-closed behavior when evidence or state cannot be trusted.
Independent quality assurance created productive friction. FIREWATCH has repeatedly found issues that successful builds and passing tests did not reveal, including gaps in authorization evidence and verification envelopes. Those findings reinforced an important principle: technically correct code is not automatically governed, verified, or ready to release.
Finally, we had to design for non-technical usability without hiding the controls that make the system trustworthy. The interface must communicate scope, cost, risk, approval, progress, and evidence clearly enough for a business leader to make an informed decision.
Accomplishments We’re Proud Of
We are proud that CASTRA has moved beyond a concept into a working, deployed product that we actively use to build and govern itself.
CASTRA now provides a deterministic Campaign–Mission–Action operating model, role-separated agent execution, explicit Commander gates, evidence-linked work history, independent verification, recoverable session continuity, cost and runtime boundaries, and a memory-only Public Demo mode.
We are especially proud of the discipline built around failure. CASTRA preserves partial work, stops on unknown outcomes, prevents silent model or provider substitution, distinguishes implemented from verified and accepted, and makes rework visible instead of treating every agent response as success.
Most importantly, CASTRA demonstrates that a non-IT business user can direct a sophisticated, multi-model development effort while retaining authority over priorities, risk, quality, and release decisions.
What We Learned
We learned that successful agentic systems need more than capable models. They need clear intent, bounded authority, deterministic business rules, visible state, durable evidence, and independent review.
We learned that human-in-the-loop should not mean placing a generic approval button at the end of an opaque process. The human needs to understand the proposed scope, exclusions, cost, risks, dependencies, and expected evidence before execution begins.
We also learned that failure handling is part of the product. Usage limits, interrupted sessions, stale state, invalid evidence, and uncertain write outcomes must be expected and designed for. A trustworthy system should stop safely, preserve what is known, and make the next permitted action obvious.
Finally, we learned that non-technical users do not need a simplified version of agentic work. They need the complexity translated into decisions they are qualified to make.
What’s Next for CASTRA
Our next step is to connect with a small business looking to get out of outdated work flows (document driven) to today's technology of data driven / automated workflows. Want to make the experience easier for non-technical users: clearer onboarding, plain-language explanations, and an obvious distinction between what an agent proposes and what a person has authorized.
Log in or sign up for Devpost to join the conversation.