Product Ladder and Market Entry Strategy
How Sókrates enters a customer account and why they never leave.
Related: Sokrates Product Bundles (Cowork, Code, Compound) covers the three service tiers. Sokrates Commercial Strategy and Revenue Model covers pricing. This page describes the customer acquisition sequence and the architectural decisions that make it work.
The Insight: The Entry Product Is Not the Box
Most enterprise AI sales start with a capabilities pitch: look what our system can do. The customer evaluates the system against their mental model of what they need, which is usually wrong because they’ve never had an AI department before. The sales cycle is long, the pilot is painful, and adoption stalls because the gap between “demo” and “daily use” is vast.
Sókrates inverts this. The entry product is not the knowledge graph, not the on-premises appliance, not the autonomous agent. The entry product is a managed Claude Teams environment — something a customer can start using on the first day, with immediate, tangible value, and zero infrastructure to deploy.
The on-premises stack, the knowledge graph, the autonomous agents — those are where the customer ends up, not where they start. Each step in the ladder delivers value on its own while creating natural demand for the next.
The Three-Tier Product Ladder
Tier 1: Managed Claude Environment
What the customer gets: A fully configured Claude Teams workspace with organisation-level administration, curated plugins and skills from the Sokrates Plugin Marketplace, Claude Projects pre-configured for their domain, and employee onboarding. This is the “outsourced AI department” in its simplest form — someone who actually knows what they’re doing sets up the AI tools and trains the staff to use them.
Why it works as an entry product:
- Immediate ROI. The customer goes from “people sneaking around with ChatGPT on personal accounts” to a governed, secure, productive AI environment in days, not months.
- Zero infrastructure. No hardware, no containers, no VPNs. It’s a SaaS configuration engagement.
- Low commitment. The customer is buying a service, not installing an appliance. The emotional barrier is comparable to hiring a consultant for a month.
- Demonstrates competence. Before asking a customer to trust you with their operational data, you show them you can make their existing tools work dramatically better.
What Sókrates delivers:
- Organisation and workspace setup with security policies, SSO if applicable, and seat management.
- A curated set of Claude Skills and plugins from the marketplace — not generic, but selected and configured for the customer’s industry and workflows.
- Employee training: how to use Claude effectively for their specific job functions.
- Ongoing administration: user management, plugin updates, skill refinement based on usage patterns.
Revenue: Captured within the standard retainer model. The Claude Teams seat costs are passed through at cost; the retainer covers Sókrates’s expertise in configuring and managing the environment.
Tier 2: Eidos Knowledge Graph via MCP
What the customer gets: The Eidos knowledge graph, built from their operational data, exposed as an MCP server that connects directly to their existing Claude Teams workspace via Claude Cowork. Their AI tools now understand their business — not in the generic sense of a fine-tuned model, but in the structural sense of knowing how their systems, teams, processes, and data relate to each other.
Why this is the natural next step:
- The customer is already using Claude daily (from Tier 1). They’ve experienced what it can do with generic knowledge. The pitch for Tier 2 is: “What if Claude actually understood your business?”
- The MCP interface means no change to the customer’s workflow. They keep using Claude exactly as before. Eidos simply makes it smarter about their specific context.
- The knowledge graph is hosted — Sókrates manages Eidos, the customer connects to it. No hardware on their end.
What Sókrates delivers:
- Eidos instance provisioned and seeded from the customer’s operational systems via the schema discovery pipeline (OpenAPI specs, database introspection via Singer SDK, document ingestion).
- MCP server exposed to the customer’s Claude Cowork environment.
- Curator Agent running daily maintenance — consolidating duplicates, flagging contradictions, keeping the graph fresh.
- Ongoing enrichment as new data sources are connected.
The critical architectural decision: Eidos already exposes the knowledge graph as an MCP server. This is not a feature that was added for this product tier — it is the native interface. Claude Cowork connects to MCP servers. The product ladder is a consequence of the architecture, not a retrofit.
Revenue: Higher retainer tier reflecting the ongoing Eidos hosting, data ingestion, and graph maintenance. The customer is now buying continuous intelligence, not just tool configuration.
Tier 3: On-Premises Sókrates
What the customer gets: The full Sókrates stack — physical appliance (the box), local Eidos instance, Hermes Agent for channel I/O, the Sókrates Agent running continuous operational intelligence, and (on DGX Spark deployments) fully local inference. Their data never leaves their office.
Why this is the natural escalation:
- European data sovereignty requirements tighten over time. The customer hits a wall where cloud-hosted Eidos (Tier 2) cannot access certain sensitive systems due to GDPR, sector-specific regulation, or board-level policy.
- The transition is seamless: same MCP interface, same knowledge graph schema, same Claude integration. The customer barely notices the difference. What was cloud-hosted is now local. What was API inference is now on-device.
- The Sókrates Agent adds proactive intelligence — it doesn’t wait for the customer to ask questions; it continuously maps their operational topology and surfaces inefficiencies.
What Sókrates delivers:
- Hardware provisioned, NixOS image flashed, deployed behind the customer’s firewall.
- Full DMCG pipeline for schema ingestion and self-healing.
- Hermes Agent configured for the customer’s channel topology (Slack, Teams, email, etc.).
- The Sókrates Agent in continuous operation (four-mode cycle: interrogation, mapping, surfacing, validation).
- Fleet management integration for remote monitoring, updates, and Basis access.
Revenue: Full retainer as described in the Sokrates Commercial Strategy and Revenue Model. This is where the highest-value, highest-margin engagements live.
The Constant: MCP as the Product Surface
Across all three tiers, the interface between Sókrates and the customer’s AI tools is MCP (Model Context Protocol). This is not accidental — it is the single most important architectural decision in the product.
- Tier 1: Claude Skills and plugins interact with external services via MCP.
- Tier 2: Eidos exposes the knowledge graph as an MCP server. Claude Cowork connects to it natively.
- Tier 3: The same MCP server, now running locally on the box, is accessed by the same Claude tools.
The customer never changes how they work. The deployment topology changes underneath. This is why the transition between tiers feels effortless — because from the customer’s perspective, nothing changes except that their AI gets progressively smarter and more autonomous.
The Plugin Marketplace as a Compounding Asset
The Sokrates Plugin Marketplace is the engine that makes Tier 1 immediately valuable and creates the flywheel for Tiers 2 and 3.
What it contains:
- Collected plugins — best-of-breed open-source and third-party Claude plugins, curated, tested, and configured for Icelandic SME use cases.
- Bespoke automations — domain-specific plugins built by Sókrates during customer engagements, generalised and added to the marketplace.
- Domain expertise bundles — pre-configured Claude Projects, Skills, and plugin sets for specific verticals (FinTech, logistics, professional services, etc.).
Why it compounds:
- Every plugin built for one customer is reusable across the market. The cost of building is amortised; the value multiplies.
- Each new customer engagement surfaces new automation opportunities. The marketplace grows faster as the customer base grows.
- The bundles architecture in the codebase (Cowork, Code, Compound packages) maps directly to this — tiered plugin sets that scale in sophistication with the customer relationship.
Competitive moat: A company choosing between “set up Claude ourselves” and “hire Sókrates” is not comparing AI capabilities — Claude is the same either way. They are comparing “figure out plugins, skills, and workflows from scratch” versus “get a curated, proven, domain-specific automation suite on day one.” The marketplace is the moat.
Customer Journey: A Concrete Example
A 45-person Icelandic FinTech company. Four operational systems (Navision ERP, HubSpot CRM, Jira, Confluence). AI adoption is currently three employees using personal ChatGPT accounts.
Month 1 (Tier 1): Sókrates sets up Claude Teams. 25 seats. FinTech plugin bundle installed — includes skills for regulatory document review, compliance checking, and financial analysis templates. Two half-day training sessions. Within two weeks, the entire product team is using Claude for documentation, the finance team is using it for report generation, and the compliance officer has automated 60% of their regulatory review workflow.
Month 4 (Tier 2): The COO asks: “Can Claude understand our actual customer data?” Sókrates connects Eidos to HubSpot and Navision via MCP. The knowledge graph maps their customer relationships, product offerings, and financial flows. Claude can now answer questions like “which customers have overdue invoices AND open support tickets?” by querying the graph — something that previously required a report from finance and a report from support and someone to manually cross-reference them.
Month 8 (Tier 3): The company is handling EU regulatory reporting and cannot send transaction data to cloud providers. Sókrates deploys the box. Same MCP interface, same Claude tools, but Eidos now runs locally with the full Sókrates Agent. The agent identifies that their invoice approval chain routes through four departments when policy requires two — a bottleneck that costs two days per approval cycle. Nobody knew this because nobody had ever mapped the actual approval flow across all four systems simultaneously.
Month 12 and beyond: The customer is a Compound-tier engagement. The Sókrates Agent is a functional member of their operations team. The knowledge graph has accumulated eight months of operational intelligence. The FinTech plugin bundle has been enriched with six automations specific to this customer’s workflows, three of which have been generalised and added to the marketplace for other FinTech customers. The customer’s retainer has increased (more seats, expanded scope) but their cost-per-insight has decreased dramatically.
Why the Architecture Is Not Over-Engineered
A common first impression of the Sókrates technical stack — NixOS appliances, fleet management, knowledge graph, ontological type system, multiple hardware tiers, channel integrations — is that it is over-built for a pre-revenue product. This is wrong, and the product ladder explains why.
The architecture was not built for a single product. It was built for three products that share the same technical substrate:
- The managed Claude environment (Tier 1) requires the plugin marketplace, the skills system, and the organisational administration layer.
- The hosted knowledge graph (Tier 2) requires Eidos, the Hyle type system, the schema ingestion pipeline, the MCP server, and the Curator Agent.
- The on-premises deployment (Tier 3) requires NixOS, fleet management, Hermes, nftables security, the Sókrates Agent, and the hardware tiering.
Nothing in the stack exists for its own sake. Every component serves at least one tier of the product ladder, and most serve all three. The architecture was pre-computed for the product — not the other way around.
The Development Model: Three, Not One
Sókrates is built by a team of three: the founder, Claude (orchestrating and executing via Claude Code with swarms of specialised subagents), and the Sókrates system itself (as it becomes capable of reasoning over its own knowledge graph and contributing to its own development).
This is not a metaphor. A single development session routinely dispatches 15+ specialised subagents — implementing, testing, reviewing, and fixing code across dozens of files — while the founder provides strategic direction from a mobile phone. The development velocity is not that of a solo developer with AI assistance; it is that of a coordinated engineering team where the coordination overhead is near zero.
As the knowledge graph matures, the system will increasingly bootstrap its own development: reasoning over the graph to identify gaps, comparing against the roadmap, and proposing next steps. The self-improvement flywheel described in the Technical Architecture Whitepaper is not a future aspiration — it is the development methodology.
During development, model selection is unconstrained. The team can dispatch Claude 4.6 Opus orchestrating swarms of specialised agents at maximum reasoning depth for architectural decisions, then switch to fast models for mechanical implementation. The DGX Spark and Gemma 4 31B constraint applies to customer deployments, not to building the product.