Sico Digital Worker Platform
Run supervised Digital Workers reliably and improve their capabilities from production experience.
The evidence shows JWT authentication, Casbin RBAC, HMAC-signed sandbox traffic, isolated execution, and tests rejecting Android path traversal. The architecture also identifies the main HTTP, gRPC, persistence, model-provider, and execution-trace flows. The security policy directs operators to rotate example secrets, use TLS, restrict data-service networks, and report vulnerabilities privately. Deductions apply because the agent exposes high-impact shell, deletion, uninstall, and network capabilities without a demonstrated fine-grained permission inventory, per-operation confirmation, or platform-wide approval policy. Encryption, retention, deletion, and provider-transfer rules for sensitive data are not comprehensively documented. Lock files, a pinned Ruff version, and CI offer some dependency discipline, but some tools are installed with latest and no vulnerability scan, SBOM, or patch automation is shown. Tested Android snapshots provide scoped recovery, not general rollback for every tool or external system. Attribution, third-party acknowledgements, trademark terms, and official Microsoft provenance are clear, justifying full source-attribution marks.
The README's Android actions, structured responses, sandboxing, recovery, and error behavior broadly agree with the supplied unit tests. CI covers Go and Python tests, race detection, compilation, and multi-language linting. Parsers raise specific errors for missing fields, unsupported actions, invalid speeds, unknown applications, and ADB failures, while connection loss has an explicit retry path, so failure messaging is thorough. Deductions apply because no CI results are supplied; core tests can pass by skipping when none are found, device integration tests normally skip without an environment variable, and frontend lint skips when separately distributed source is absent. Runtime availability also depends on several databases, messaging and storage services, plus external model credentials, although setup requirements are documented.
The project clearly identifies BPO providers, enterprises, and developers, with testing, data processing, support, and moderation scenarios and four distinct human or worker roles. Android parsing defines precise verbs, parameters, formats, and rejection cases, while the platform advertises multiple model adapters and Compose, Kind, and Helm deployment paths. Deductions apply because repository-wide shell, network, filesystem, memory, and skill interfaces lack a complete static specification of allowed scope, trigger precedence, conflict resolution, or environment-specific permission reduction. Android setup depends on MuMu Player, and the full environment requires recent Go, Python, and Node toolchains plus numerous infrastructure services.
The README has a strong structure covering overview, architecture, features, quick start, repository layout, documentation, contribution, and security entry points. Installation documents prerequisites, templates, two run modes, health checks, the default-account warning, and teardown commands, justifying full marks for information architecture and install notes. The MIT text matches the metadata, while contribution routes, security response channels, maintenance statements, and verified organization provenance make licensing and responsibility clear. Deductions apply because the project is pre-1.0, the Evaluation Loop is explicitly planned, frontend source is separately distributed, and stable supported release lines do not yet exist. These limitations are disclosed but not consolidated into a comprehensive limitations section. Recent releases and a roadmap are linked, but there is no complete changelog or compatibility policy in the supplied material. Examples and troubleshooting are referenced, but no dedicated FAQ is shown. Naming is mostly stable, though Digital Worker, agent, skill, and evolution concepts retain some overlap.
The platform describes usable outputs including step-level trajectories, structured actions, environmental feedback, conclusions, failure classifications, and reusable Playbooks, supported by a UI, API documentation, and health endpoint. Tests substantiate structured parsing and several failure cases. The combination of Cortex, Action, Memory, human supervision, replayable sandboxes, and experience distillation plausibly adds value beyond a thin model-and-tool wrapper. Deductions apply because the main claims about production reliability, continuous improvement, and 82.9% task success are assertions in the supplied material without evaluation protocol, comparison data, or result artifacts. The stack requires paid or hosted model access, several infrastructure services, containers or Kubernetes, and optionally an emulator, but offers no quantified resource, latency, operating-cost, or benefit tradeoff.
Many claims point to named repository areas, configuration paths, tests, CI workflows, and the security policy. Android action syntax, path controls, restore behavior, and error handling receive useful corroboration across multiple test files. The README also labels the Evaluation Loop as planned and distinguishes training-based from training-free evolution. Deductions apply because only a small subset of implementation and tests is supplied, leaving many platform-wide claims traceable only to the README. The production validation, reliability improvement, and 82.9% claims lack experimental methods or raw results in the supplied files. Linked technical reports and external model pages were not included as source material and therefore cannot independently corroborate those claims here. Some aspirational language remains insufficiently separated from demonstrated fact.
- Agent capabilities include shell execution, file deletion, application removal, APK installation, and external network access. Validate fine-grained authorization, hazardous-action confirmation, egress controls, and audit policy before production use.
- The development environment has a published default account and model plus Mem0 configurations require sensitive credentials. Rotate or remove defaults before exposure and verify that secrets cannot enter logs, trajectories, or long-term memory.
- The tested Android restoration path deletes files created after the baseline snapshot. Confirm sandbox isolation and backup boundaries so real user data or shared devices cannot enter that recovery scope.
- Do not treat the README's production-validation, continuous-reliability, or 82.9% success claims as independently established by this static review.
- CI contains conditional skips and some build tools are installed using latest. Verify actual CI results, dependency pinning, vulnerability scanning, and complete test coverage before release.
What does this agent do, and when should you use it?
Sico is an open-source platform for building, operating, and evolving Digital Workers in enterprise and BPO workflows. Its runtime combines a React frontend, a Go/Gin backend, and a Python asyncio Core connected through Nginx, HTTP/SSE, gRPC, and reverse gRPC. Each worker uses a Cortex, Action, and Memory & Sense structure to plan and execute work inside an observable Sandbox, producing structured trajectories of actions, intermediate states, tool outputs, and environmental feedback. A Reflector-to-Curator pipeline turns completed runs into a project-and-agent-specific Playbook that is injected into later runs. The platform supports several model providers and can be self-hosted with Docker Compose, Kind, or production Helm charts; Android GUI execution additionally depends on MuMu Player. It is a better fit for teams prepared to operate a multi-service system and a human-supervised improvement loop than for applications seeking a small embedded chat agent.
An Operator supplies a goal, and the Execution Loop runs the Cortex–Action–Memory stack inside a Sandbox while recording actions, tool results, intermediate states, and environmental feedback. Core handles reasoning, LLM orchestration, tool execution, and experience accumulation; its built-in toolkit covers file I/O, grep, shell/command execution, web search and fetch, document parsing, long-term memory retrieval, plan inspection or cancellation, reporting, and sandbox operations. The Go Backend exposes HTTP APIs and manages persistence, RBAC, and sandbox orchestration. Through reverse gRPC, Core calls the Backend to persist messages, update state, and send notifications while remaining database-free. The Evolution Loop sends completed trajectories through Reflector → Curator, producing a per-(project, agent) Playbook for automatic injection into the next run; the same signals may also feed base-model training. Mem0, Qdrant, SeaweedFS, Redis, and MySQL support turn context, long-term facts, knowledge bases, and project-scoped memory. For Android work, pooled emulator sandboxes provide H264 live views, VNC, step-level traces, and replayable runs. The described Evaluation Loop is planned rather than a delivered feature.
- A BPO provider running ongoing data-processing, customer-support, or content-moderation work for clients, with Operators assigned to monitor, correct, and improve Digital Workers.
- An enterprise operations team whose interfaces, rules, and data formats change frequently and that wants execution traces and reusable Playbooks instead of repeatedly repairing static scripts.
- A mobile testing team performing black-box tests in isolated Android emulators while retaining live video, detailed operation traces, and replayable runs.
- An internal AI platform group that needs one LLM Hub for OpenAI, Azure OpenAI, Anthropic, Gemini, OpenRouter, or compatible endpoints rather than a single-provider runtime.
- A development team registering and versioning domain capabilities as first-class Skills while maintaining project-specific knowledge and long-term experience.
- An organization needing human-user RBAC through JWT and Casbin plus HMAC-signed machine-to-machine traffic for sandbox infrastructure.
What are this agent's strengths and limitations?
- It goes beyond a thin model-and-tools wrapper by combining Cortex, Action, and Memory & Sense with project knowledge, sandbox execution, and platform persistence.
- The Reflector → Curator pipeline converts production trajectories into per-project, per-worker Playbooks and automatically injects them into later runs without requiring model retraining.
- LLM Hub explicitly supports OpenAI, Azure OpenAI, Anthropic, Gemini, OpenRouter, OpenAI-compatible providers, and generic HTTP JSON or binary endpoints, reducing dependency on one model vendor.
- Structured traces, isolated environments, and replay support make executions observable; the Android sandbox adds H264 live viewing and VNC for supervised GUI work.
- Docker Compose, Kind, and production Helm paths are documented alongside JWT, Casbin, and HMAC controls, covering local development and more structured deployments.
- The full deployment is not lightweight: its Compose stack includes nginx, frontend, backend, Core, MySQL, Redis, Kafka, SeaweedFS, and Qdrant, creating substantial operational overhead.
- Adopters must configure both a default LLM and Mem0 embedder/LLM credentials in addition to supplying a model API key.
- Android Tester has a separate MuMu Player dependency and requires an emulator API service plus device bootstrapping.
- The Evaluation Loop and its L1–L4 failure attribution are marked as planned, so they should not be treated as currently available functionality.
- Go 1.25+ and Python 3.13+ may require toolchain upgrades in established enterprise environments.
- The documented seed login is intended only for local development and becomes a security risk if it is not rotated or removed before external exposure.
How do you install or deploy this agent?
Prerequisites are Docker, Docker Compose, make, and a valid API key for at least one supported LLM provider. Run:
git clone https://github.com/microsoft/Sico.git
cd Sico
cp .env.example .envEdit .env, then create deploy/config/llmhubs/<your-model>.yaml from deploy/config/llmhubs/model-template.yaml or another *-template.yaml and include default: true. Configure memory with:
cp deploy/config/mem0/mem0_config_template.yaml deploy/config/mem0/mem0_config.yamlEdit that file with the embedder and LLM credentials. For the recommended local setup, run:
make compose-upThis builds and starts nginx, frontend, backend, core, mysql, redis, kafka, seaweedfs, and qdrant. Use make kind-up instead for a local Kind cluster. Android Tester users must also install MuMu Player and run make emulator-setup, make emulator-status, and make emulator-bootstrap.
How do you use this agent?
After make compose-up, open http://localhost:8080/login and sign in with the development seed account [email protected] and password operator; rotate or remove it before exposing the deployment. API documentation is available at http://localhost:8080/api/sico/docs/index.html. Verify the first running deployment with curl http://localhost:8080/api/sico/health. The configured default LLM serves the platform's workers; an Operator supplies goals through the platform, after which Sico executes the work, persists its trajectory, and accumulates experience. Completed strategies and recurring failures pass through Reflector and Curator into the Playbook used by later runs for the same project and worker. In Kind mode, make kind-restart SVC=core rebuilds and rolls out one service, make kind-stop stops the Kind containers without deleting data, and make kind-down removes the local cluster data.
How does this agent compare with similar options?
Compared with traditional automation built from static scripts or predefined workflows, Sico treats execution as an evolving capability: runs produce structured trajectories, an Operator can supervise or intervene, and Reflector plus Curator turn experience into a reusable Playbook. The tradeoff is a considerably larger multi-service platform, explicit model and memory configuration, and defined human operating roles rather than a script-only deployment.
FAQ
Does Sico require OpenAI models?
Can the platform be self-hosted?
Where do people remain involved?
Will a worker automatically learn from every failure?
What extra setup is required for Android automation?
make emulator-bootstrap. This emulator dependency is optional for other uses of the platform.