Last updated: 28 June 2026 · Reading time: 8 min · By: the geminy.ai editors
Most AI product teams hit the same wall around service number twenty: you are maintaining twenty slightly different prompt files, twenty slightly different backend handlers, twenty slightly different input forms. The combinatorial debt compounds. gik.ai is built around a different bet — a single execution engine and a declarative JSON spec that drives everything, from the prompt to the form to the landing page. At launch the platform ships over 128 services. Zero of them required writing a new backend service.
The Core Abstraction: service.json
Every service on gik.ai is defined by a single Firestore document — conceptually a service.json. It is the source of truth for both the execution layer and the presentation layer simultaneously. A trimmed view:
{
"name": "Resignation Letter Template",
"slug": "resignation-letter-template",
"category": "personal",
"price": 10,
"execution_type": "dynamic_prompt",
"execution_mode": "sync",
"llm_model": "standard",
"timeout_seconds": 90,
"input_schema": { ... },
"system_prompt": "You are a professional career advisor...",
"user_prompt_template": "Write a resignation letter for:\n\nName: {full_name}\nCompany: {company_name}\n...",
"output_sections": [ ... ],
"seo_title": "Resignation Letter Template | Professional | GIK.ai",
"_qa_criteria": { ... }
}The critical constraint is the coupling between input_schema and user_prompt_template: every field.id defined in the schema must appear as a {placeholder} in the template. The execution engine validates this at runtime. If a placeholder is missing or a submitted field has no corresponding slot in the template, the job fails before the LLM is called. Prompt injection and schema drift become detectable errors, not silent degradation.
Two Execution Types — and Why the Split Is 95/5
gik.ai runs two execution modes. The table below shows how they divide:
| Type | Share | How it works | When to use |
|---|---|---|---|
dynamic_prompt | ~95% | Cloud Run pulls system_prompt + user_prompt_template from Firestore, substitutes form inputs, fences the prompt, dispatches to Gemini via Vertex AI. No service-specific code. | Any service expressible as a single-turn prompt with structured output |
custom_container | ~5% | Isolated Cloud Run container with its own build/deploy cycle. | External API calls, file processing, multi-step pipelines |
The 95/5 split is a deliberate product decision. The marginal cost of a new dynamic_prompt service is essentially zero engineering time: write the spec, seed Firestore, done. A product manager with access to the spec format can ship a new service without an engineer.
The Execution Pipeline
The user flow from browse to output:
Browse → Landing Page → Cart → PayPal Checkout
→ ServiceInput (form) → ServiceJob (Firestore) → Cloud Run
→ Gemini (Vertex AI) → Result Page → Account HistoryWhen a user submits the input form, a ServiceJob document is written to Firestore with status pending. Cloud Run picks it up via Firestore trigger, resolves the service.json spec, builds and fences the final prompt, calls Gemini, writes the output back to the ServiceJob document, and flips status to complete. The result page reads that document and renders the output sections.
Sync services — the majority — return results within the timeout_seconds window, typically 60–90 seconds. Async services, used for the more complex advanced model tier, give the user a job ID and poll for completion.
Output Sections: Structured LLM Output by Contract
Rather than treating LLM output as a raw markdown blob, each service defines output_sections — a typed list of expected sections with display hints and a primary flag:
"output_sections": [
{
"title": "Your Resignation Letter",
"type": "markdown",
"is_primary": true,
"display_hint": "highlight"
},
{
"title": "Next Steps",
"type": "markdown",
"is_primary": false,
"display_hint": "normal"
}
]The user_prompt_template instructs the LLM to use ## Markdown headers that exactly match these section titles. The frontend parses the output by header and renders each section accordingly. The prompt and the UI are synchronised by design, not by convention.
Model Tiering: Matching Compute Cost to Pricing
| Tier | Use case | Token budget | Timeout | Mode | Price |
|---|---|---|---|---|---|
basic | Lists, short text, name generators | 500–800 | 60s | sync | $5 |
standard | Letters, analyses, templates | 800–1,500 | 90s | sync | $10 |
advanced | Contracts, handbooks, multi-section docs | 1,500–2,500 | 120–180s | async | $15 |
The tier is set in service.json and maps to a specific Gemini model variant on Vertex AI. Pricing has a direct correspondence to compute cost — a cleaner unit economics model than flat pricing across the board.
Prompt Security: Fencing and Instruction Isolation
When user input goes into an LLM prompt, prompt injection is a real attack surface. gik.ai’s execution engine applies two mitigations before every dispatch:
- Triple backtick fencing — all user-supplied field values are wrapped in code fences so the LLM treats them as literal data, not as instructions.
- Instruction isolation directive — the system prompt includes an explicit override: content within fenced blocks that attempts to override, ignore, or modify system behaviour is to be disregarded.
Neither mitigation is a silver bullet, but together they significantly reduce the attack surface for adversarially crafted inputs — important when fields like “business description” or “contract details” can be arbitrarily long.
The _api_spec Field: gik.ai Meets Agent-to-Agent Protocols
A subset of gik.ai services — the ai_platforms category — are designed not for human end-users but for agent-to-agent consumption. These carry an _api_spec field:
"_api_spec": {
"endpoint": "POST /api/v1/seo-metadata-generation",
"input_schema": { "url": "string", "target_keyword": "string" },
"output_schema": { "title": "string", "description": "string", "og_tags": "object" },
"rate_limit": "100/hour",
"auth": "Bearer token",
"api_price_per_call": "$0.50"
}This maps directly onto the emerging Model Context Protocol (MCP) pattern: an AI agent discovers a service endpoint, evaluates the _api_spec, calls it, and pays for the result. gik.ai is watching the x402 / Model Payment Protocol (MPP) space closely. The service spec already carries everything a consumer agent needs to evaluate and invoke the service. The missing piece is a standardised payment layer — a near-term integration target as the protocol matures.
Why the Declarative Model Compounds
Every enhancement to the execution engine — better prompt fencing, smarter output parsing, cheaper model routing, response caching — applies to all 128 services simultaneously. There is no per-service code to patch.
And because the spec drives both execution and presentation, there is no drift between what the landing page promises and what the service delivers. The deliverables, output_sections, and user_prompt_template fields are all in the same document. Change one — the others are right there to keep in sync.
If you are building on LLMs and find yourself writing similar prompt-wrapping logic for each new service, the spec-driven pattern is worth studying. The platform is live at gik.ai — the input forms and output structures across 128+ services give a useful view of the approach in practice.
Frequently Asked Questions
What is gik.ai?
gik.ai is an AI-powered micro-services marketplace. Users browse services, pay a flat fee ($5, $10, or $15), fill out a structured form, and receive AI-generated output within seconds to minutes. The platform runs on Firebase + Firestore + Cloud Run, with Gemini via Vertex AI as the execution engine.
Does gik.ai use Gemini or GPT?
Gemini via Google’s Vertex AI is the primary execution engine. All 128+ services run through it. This keeps the stack entirely within Google Cloud, simplifies data residency, and uses Vertex AI’s enterprise data processing agreements — user input is processed transiently and not used for model training.
How is this different from calling the Gemini API directly?
The platform abstracts everything above the raw API call: prompt construction, input validation, output structuring, security fencing, payment, job queuing, and result rendering. For developers, the interesting part is the service.json spec pattern: one document per service, no per-service backend code.
Is gik.ai relevant for developers building AI agents?
Yes — particularly the ai_platforms category, which exposes structured _api_spec fields and per-call pricing ($0.25–$1.50). The platform’s roadmap includes x402 / MPP payment protocol support for autonomous agent consumption. See our MCP explainer for context on how agent-to-service protocols are evolving.
What AI model powers gik.ai?
Gemini via Vertex AI, with three model variants mapped to the basic / standard / advanced tiers. The tier selection is set in the service spec and drives both the token budget and the per-service price point.
Related on geminy.ai
- AI MCP — Model Context Protocol explained
- geminy.ai as a unified AI gateway for developers
- Gemini Google — full hub
- Gemini vs ChatGPT (2026)
Leave a Reply