I built an agent platform. Not a demo — an actual platform where every tool call is governed, audited, and scoped to a workspace.
Here's what I learned.
Every skill is a first-class citizen
The platform has 27 skills across 7 groups — platform ops, publishing (dev.to, LinkedIn), testing (a full TEA suite with risk matrices, baseline characterization, NFR audits), communication (Slack, Telegram, Gmail), knowledge (RAG + persistent memory), development, and scraping.
Skills aren't just prompts. Each one has a governed lifecycle: create, validate, version, insert into workspaces. No stray scripts.
14 integrated services, one audit trail
- GitHub (issues/PRs), Jira (tickets), Slack & Telegram (messaging)
- Gmail, Google Calendar, Google Drive (OAuth2)
- LinkedIn (profile + post publishing), Dev.to (blog)
- Knowledge Base (RAG retrieval), Memory (persistent cross-session)
- Web Search, Transcribe (Whisper)
Every outbound call goes through a platform_cli dispatch op or a service_call adapter — same audit pipe, same trace ID.
The CLI is the source of truth
You don't edit config files and hope. You verify with loop_list, policy_show, skill_list, service_list, workflow_catalog. If you can't see it there, it doesn't exist.
Testing isn't an afterthought
The TEA (Test Engineering Architecture) suite ships 6 workflows: test design (risk-matrix), baseline characterization (golden-master diffing), NFR evidence audits, automated test generation, test review, and requirement-to-coverage tracing. All output is committed JSON or markdown — no proprietary formats.
The honest part
Not everything is production-ready. 4 of 27 skills are blocked (missing services or out of workspace scope). The model is deepseek-chat with deepseek-reasoner fallback — pragmatic, not exotic. Workspace scratch files TTL at 24 hours. Risky commands (kubectl delete, helm uninstall) are pattern-blocked.
But the core idea works: governed agent tools, scoped to a workspace, with real integrations, real memory, and real audit. That's more than most agent frameworks deliver.
If you're building agents that need to touch real APIs (not just generate text), consider: every integration should be a governed skill, every call should be traced, and you should be able to verify state by reading back from the platform — not by guessing.
Top comments (1)
The focus on governed skills and the CLI source of truth is exactly what's missing in most agent frameworks today. When designing the TEA suite, I wonder about testing failure modes across services.
For example, if a workflow requires reading from Google Drive (OAuth scope A) and then posting to LinkedIn (scope B), how do you test the dependency chain when one service returns an ambiguous 403 error? Defining 'success' becomes less about output JSON and more about verifiable state changes in three separate systems.