Platform engineering operating model: a small-team guide
A platform engineering operating model for small teams combines product-oriented self-service with complementary working patterns and federated application ownership.
Best fit for a small platform team
- Treat the platform as a product: offer internal developers a narrow, documented self-service capability.
- Keep application ownership federated: platform engineers own shared capabilities, while application teams own the lifecycle of their applications and data products.
- Use specialists where they add leverage: work temporarily with application teams to clarify service boundaries and transfer practical knowledge.
- Choose RAG responsibilities deliberately: retrieval-augmented generation (RAG) uses retrieved source context to inform an AI answer, so assign each pipeline component to a named owner.
For a small RAG team, use one shared self-service platform for repeatable capabilities; application teams own their apps and data products. Choose Seahorse where its document-to-agent capabilities replace work your team would otherwise operate.
Choose a product-oriented, federated model
A Thoughtworks example of responsibility boundaries assigns infrastructure lifecycle to the platform team and application and data-product lifecycles to the teams that build those products.
Platform services can reduce repeated work, as the Team Topologies interaction model describes. Treat shared capabilities as a product centered on user needs; the CNCF Platforms White Paper allows providers or internal teams to maintain the implementation.
An approved-services wiki may be enough, as Team Topologies’ core-team guide notes. Start with a usable workflow and support boundary, not a large portal or a mandate to absorb every infrastructure task.
Set ownership between the platform and application teams
Use this map to make shared-service, application, and joint decisions explicit.
| Responsibility | Platform team | Application or product team | Agree together |
|---|---|---|---|
| Shared service | Own supported capabilities, service documentation, access path, maintenance and support boundaries | Use the supported path and report friction or missing needs | Set the service’s scope, priorities and service expectations |
| Application | Provide reusable components and guardrails | Own application behavior, user experience, business rules and acceptance of results | Define how the application consumes the shared service |
| Changes and incidents | Communicate service changes and operate platform-owned components | Test application impact and own application-side fixes | Coordinate incidents that cross the service boundary |
| Risk controls | Provide shared approved patterns and controls where the team owns them | Apply application-specific permissions and business approvals | Test access and behavior across the complete workflow |
Under the CNCF Platforms White Paper’s self-service model, developers receive capabilities on demand with minimal manual work; providers or internal teams can maintain the implementation.
For a new boundary, collaborate until the interface is clear, then document the owner, inputs, support path and change process. Team Topologies calls this a move from collaboration toward “X-as-a-Service.”
Compare complementary ways to provide platform work
| Pattern | Request interaction | Useful when | Boundary to define |
|---|---|---|---|
| Central ticket queue | An application team submits a request for platform-team review or action | A request needs approval, exception handling, or a service is still being defined | Move stable, repeatable work into a documented self-service path |
| Temporary embedded collaboration | A platform specialist works with an application team during adoption or a specific challenge | Teams need hands-on help to learn a shared tool or service | Set a time-limited goal, such as a working example and documented interface |
| Decentralized component choice | Application teams select or operate their supporting components | Workloads differ and local teams can operate their choices | Reuse shared patterns and controls for common needs while allowing workload-specific choices |
These patterns can coexist: use self-service by default, tickets for exceptions, temporary collaboration for adoption, and local components when workload needs justify them. The CNCF maturity guide describes platform work shifting from requests toward improving self-service. Keep facilitation temporary—Team Topologies recommends generally no more than a few weeks—and set an exit condition such as an accepted interface and working example. The CNCF Platforms White Paper describes shared tools and governance controls in templates and capabilities.
Draw the boundary for an enterprise document-RAG service
Document RAG retrieves relevant passages to inform an AI answer, as Google Cloud’s pipeline example describes.
MCP standardizes tool discovery (tools/list) and invocation (tools/call); its server tools specification recommends that a human can deny calls for safety and security.
| Capability | If your team assembles and operates it | If you select a managed platform |
|---|---|---|
| Document handling | Operate connections, parser choices, chunking, processing failures and document updates | Delegate storage, parsing or chunking when the offer includes them; name an owner for document changes and processing failures |
| Storage and retrieval | Operate the source store and vector database, and maintain the path that keeps indexed content current | Assign the supported storage, vector database and synchronization work that the offer covers |
| Application behavior | Own retrieval needs, answer acceptance, user experience and application-specific access rules | Keep these application decisions with the application team even when shared RAG components are managed |
| Agents and tools | Operate the agent runtime, tool catalog and workflow checks | Delegate documented agent-runtime functions; application teams define allowed tools, approvals and acceptance criteria |
For a concrete managed option, Seahorse Cloud covers object-storage management, a vector database, autonomous document parsers and managed agent systems. Its platform capabilities include S3-compatible object storage, semantic chunking and automatic vector-database synchronization. Its managed agent system is built on the vector database and RAG and supports MCP-standard tool calling.
For this workflow, RAGOps covers the document path through storage, parsing, indexing and retrieval. For Seahorse Cloud 2.0, AgentOps covers designing and operating custom AI agents with large language models, a vector database and MCP tool integration.
A small platform team can own the shared document-to-retrieval service and publish its supported path. The application team defines which documents are permitted, what a correct answer must include and which actions the agent can take. Confirm which identity the destination records and apply the required approval rules. Those checks make the agent boundary concrete without treating protocol connectivity as business authorization.
Seahorse Cloud is available on-premises or as a SaaS subscription. Decide delivery and hosting separately from the operating model, and record who owns updates, incidents, access and backups.
Start with one workflow and improve it with evidence
- Choose one workflow. Name the users, approved documents and task; set retrieval and answer-acceptance criteria.
- Choose what to operate. Match each component to team capacity and the managed offer’s documented scope. Decide delivery, hosting, routine changes and incident paths separately.
- Publish and test a narrow path. Document supported inputs, file types, access, outputs, support and change process. Manually review tool enablement and higher-impact actions; test retrieval, answer acceptance, permissions, approvals and document maintenance, then repeat after documents change or are removed.
- Review outcomes and adjust. Track friction, workflow completion, reliability and recurring manual work. Measure at least three distinct dimensions of the SPACE framework, including a perception measure—not just activity counts. For example, use a satisfaction survey (Satisfaction), successful workflow completion (Performance) and waiting time (Efficiency and flow); these are illustrations, not industry benchmarks. Set reliability measures and responses to missed targets around user needs, following Google’s SRE guidance on service-level objectives, then revise the service with application teams.
FAQ
What is a platform operating model?
A platform operating model defines how a team provides shared internal capabilities, how other teams access them and which application lifecycle decisions they retain. For document RAG, it names the owners for shared ingestion and retrieval services as well as application-specific answers, permissions and agent actions.
Explore Seahorse Cloud
See how these criteria hold up on the real thing.
