Semantic Workspace Steward

A conversational cloud steward that uses Strands + Amazon Bedrock + MCP to interpret requests while deterministic policy, approval, and execution keep cloud authority out of the LLM.

Comment

The Problem

Cloud infrastructure is becoming easier to control through natural language, but that creates a difficult question: how much authority should an AI actually have?

Giving an LLM direct access to cloud mutation APIs makes the interface convenient, but also creates a dangerous coupling between interpretation and execution. A misunderstood request, hallucinated action, or prompt injection should never become a cloud mutation.

The Solution

Semantic Workspace Steward (SWS) is a conversational cloud operations assistant built around a simple principle:

AI interprets. Deterministic systems decide and execute.

Users can interact with SWS through text or an Alexa+-inspired voice experience. A Strands agent running with Amazon Bedrock interprets the request and can use a strictly bounded set of read-only MCP tools to understand the workspace.

The LLM does not receive the execution tool, does not directly call AWS mutation APIs, cannot bypass approval, and does not make authoritative policy decisions.

Instead, workspace facts, policy evaluation, human approval, execution, and auditing remain deterministic system responsibilities.

SWS exposes a real self-hosted Streamable HTTP MCP server with nine deterministic tools. Only eight read-only tools are available to the conversational model; decide_ticket is deliberately excluded from its tool catalog.

The result is a cloud assistant where the conversational layer can be intelligent without becoming the authority over the infrastructure.

What We Built

The public SWS demo includes:

  • Conversational text and voice interaction
  • Alexa+-inspired Cloud Action Briefings
  • A visible Activity and MCP tool trace
  • Deterministic workspace inspection and evaluation
  • A real Streamable HTTP MCP server
  • Strands + Amazon Bedrock conversational orchestration
  • Responsive cloud-console UI
  • Explicit separation between public simulation and real execution

The public demo uses a synthetic cloud workspace and cannot perform destructive AWS actions.

Separately, the underlying SWS execution architecture has been tested against real AWS infrastructure. During development, SWS performed one real EC2 StopInstances operation through its bounded execution path, with the resulting action independently verified through AWS CloudTrail.

Why It Matters

The interesting problem is not simply making an AI that can operate infrastructure.

It is deciding where the AI's authority should stop.

SWS treats the LLM as an interpreter and orchestrator, while deterministic components remain responsible for facts, policy, approval, execution, and auditability. This creates a clearer safety boundary for agentic cloud operations without removing the usefulness of natural-language interaction.

Built for the Alexa+ Track

SWS demonstrates an Alexa+-inspired conversational experience with text and browser voice input, contextual workspace information, action briefings, and structured tool interaction.

This is explicitly a simulated Alexa+ experience, not an official Alexa+ integration. The project also provides a real Streamable HTTP MCP server that can be used as the structured capability boundary.

Open Source

SWS is released under the MIT License. The repository contains the application, MCP server, simulator, conversational agent, safety architecture, tests, and supporting documentation.

Built With

Share this project:

Updates

Submission history