What I learned building an agent platform that actually ships

Building an agent platform that is fully functional and ready for deployment has taught me several crucial lessons. Every skill within the platform operates as a first-class entity, complete with its own lifecycle that includes creation, validation, versioning, and insertion into workspaces. This structured approach ensures that no stray scripts or unmonitored functions exist within the system.

There are 27 skills across various categories, ranging from platform operations and publishing to development and knowledge management. These skills are not mere prompts but are instead fully governed, ensuring each one is meticulously created, validated, and versioned before being integrated into workspaces. This level of control prevents stray operations and maintains a clear audit trail.

The platform incorporates 14 integrated services, all of which contribute to a unified audit trail. These include GitHub (for issues and pull requests), Jira (for tracking tickets), messaging platforms like Slack and Telegram, Gmail, Google Calendar, Google Drive (accessed via OAuth2), LinkedIn (for profile and post publishing), Dev.to (for blog posts), a Knowledge Base for Retrieval-Augmented Generation (RAG) retrieval, and a Memory system for persistent cross-session memory.

Web Search and Whisper (for transcription) are also integrated, with every outbound call passing through a platform_cli dispatch operation or a service_call adapter. This ensures consistency and traceability across all operations.

The CLI (command-line interface) serves as the single source of truth for the entire platform. Instead of editing configuration files in the dark, users verify everything through commands such as loop_list, policy_show, skill_list, service_list, and workflow_catalog. If a particular setting or configuration is not visible through these commands, it simply does not exist within the platform.

Testing is treated as a fundamental aspect of the platform's development, rather than an afterthought. The platform employs a comprehensive Test Engineering Architecture (TEA) suite that includes six distinct workflows: test design with risk-matrix analysis, baseline characterization using golden-master diffing, audits of Non-Functional Requirements (NFR), automated test generation, test review, and requirement-to-coverage tracing.

All outputs are consistently formatted as JSON or markdown, avoiding proprietary formats that can complicate interoperability.

It is important to note that while the platform is fully operational, it is not yet production-ready. Four out of the 27 skills are currently blocked due to missing services or insufficient workspace scope. The underlying model is DeepSeek-chat, supplemented by DeepSeek-reasoner for additional reasoning capabilities, representing a pragmatic choice rather than an exotic one.

Additionally, scratch files within workspaces have a time-to-live (TTL) of 24 hours to maintain security and efficiency. Certain risky commands, such as kubectl delete and helm uninstall, are pattern-blocked to prevent unintended data loss or system destabilization.

Despite these limitations, the core concept of governed agent tools—where every integration is treated as a skill, every call is traced, and state verification is achieved by reading from the platform itself—works remarkably well. This approach offers a level of control, security, and transparency that surpasses what many other agent frameworks can provide.

For those looking to build agents that interact with real APIs beyond mere text generation, implementing these principles—governed skills, traceable calls, and verifiable state—is highly recommended.