Skip to main content
In this quickstart, you’ll build a multi-agent research team with web search, an MCP tool server, a knowledge base backed by vector search, and persistent storage. You’ll see how Pragmatiks resolves complex dependency graphs and automatically propagates changes.
Time estimate: 45 minutes. Assumes you’ve completed the amateur quickstart.

What you’ll build

13 resources, wired together. Pragmatiks resolves the entire dependency graph in the correct order.

Prerequisites

  • Completed the amateur quickstart (CLI installed, authenticated)
  • An OpenAI API key (for embeddings and GPT-4o)
  • A running Qdrant instance (Qdrant Cloud free tier works)
  • A GKE cluster managed by Pragmatiks (created in the amateur quickstart)

Step 1: Secrets

Store all API keys as pragma secrets. Create secrets.yaml:
secrets.yaml

Step 2: AI models

Configure two models from different providers. Create models.yaml:
models.yaml
Each model’s api_key is a field reference pointing to a secret output. The key value is injected automatically at provisioning time.

Step 3: Tools

Give agents capabilities through tools. Create tools.yaml:
tools.yaml
The web search tool gives agents internet access. The MCP tool connects to a Model Context Protocol server — in this case, a filesystem server for reading local files.

Step 4: Knowledge base

Set up vector search so agents can query a knowledge base. This creates three connected resources: an embedder, a vector database, and the knowledge base itself. Create knowledge.yaml:
knowledge.yaml
Notice the layered dependencies:
  • The embedder references the OpenAI secret
  • The vector database references the embedder (dependency) and the Qdrant secret (field reference)
  • The knowledge base references the vector database

Step 5: Agents

Define two specialized agents with different models and capabilities. Create agents.yaml:
agents.yaml
The researcher agent uses Claude with web search, MCP tools, and knowledge base access. The writer agent uses GPT-4o with a focused writing prompt. Each agent declares its model as a dependency, so model changes propagate automatically.

Step 6: Team

Combine agents into a team. Create team.yaml:
team.yaml
The team references both agents as dependencies in its members list. When either agent changes, the team rebuilds.

Step 7: Deploy and observe

Deploy the team to your GKE cluster. Create runner.yaml:
runner.yaml
Watch the resources resolve:
All 13 resources should reach READY state. Pragmatiks resolved the dependency graph — secrets first, then models and tools, then agents, then the team, then the runner.

Step 8: Change propagation

This is where reactive dependencies shine. Swap the researcher’s model from Claude to GPT-4o and watch the cascade. Update agents.yaml — change the researcher’s model reference:
Now watch what happens:
  1. The researcher agent rebuilds with the new model
  2. The research-team automatically rebuilds because its member changed
  3. The runner redeploys because the team spec changed
You changed one line, and Pragmatiks propagated the change through three resources. No manual coordination needed.

How it works

Two mechanisms make this possible: Dependencies (Dependency[T]) link resources together. When a resource declares a dependency on another, Pragmatiks tracks the relationship. If the upstream resource changes, the dependent rebuilds.
Field references (Field[T]) inject specific output values from other resources. The referenced value is resolved at provisioning time and re-resolved when the source changes.
Resources can be applied in any order. Pragmatiks holds unresolved resources in PENDING state until their dependencies are ready, then processes them automatically.

Full YAML

pipeline.yaml

Next steps

Create a Custom Provider

Build your own provider to manage custom resource types.

Reactive Dependencies

Deep dive into the dependency resolution system.