Core Concepts
The building blocks you need to understand the Birk ecosystem and how autonomous agents work.
01Agents
Autonomous AI units. They do more than answer a question; they reason, plan, and take action toward a defined goal. Each agent starts with a persona tailored to a specific area of expertise.
A traditional LLM produces a one-off answer. A Birk Agent repeats this loop on its own until the goal is satisfied without requiring human intervention.
02Models & Open Source
Birk is built on open-source and open-weight models. Each model is selected by task type, can be fine-tuned, and runs entirely inside your own infrastructure. Your data never leaves your network.
| Model | Foundation | Use Case | Fine-tune |
|---|---|---|---|
| Birk-Fast | Open-weight LLM | Low-latency classification, summarization, translation | Optional |
| Birk-Agent-Light | Open-weight LLM | Tool-calling, multi-step tasks, code analysis | Recommended |
| Birk-Agent-Heavy | Open-weight LLM | Complex orchestration, long context, critical decisions | Recommended |
- -Data sovereignty: Models run on your servers; no data leaves your environment.
- -Customization: Fine-tune with your industry data to achieve domain-specific performance.
- -No vendor lock-in: Changing the model does not mean changing the pipeline.
03Tools & Connectors
Capabilities that let agents interact with the outside world. An agent cannot produce enterprise data by itself; it triggers tools to retrieve data or perform an action through function calling. Connectors are ready integration points for your enterprise systems.
| Tool Name (Tool ID) | Parameters | Purpose |
|---|---|---|
| execute_sql | { query: string } | Runs a read-only query against a PostgreSQL database. |
| read_local_file | { path: string } | Reads log or configuration files on the server. |
| send_slack_alert | { channel: string, msg: string } | Sends an incident or report notification to a team channel. |
04Pipeline & Orchestration
Splitting complex tasks into smaller pieces and processing them across multiple agents sequentially or in parallel. The orchestrator agent distributes the work, worker agents produce the solution, and every step remains observable, repeatable, and independently testable.
“Analyze the sales decline over the last 30 days, find possible causes, and report back.”
Splits the request into subtasks, selects which agents should run in parallel, and waits for results.
Runs SQL queries and extracts sales and customer data for the period.
Scans error, outage, campaign, and integration logs.
Compares findings and flags anomalies and likely causal relationships.
Resolves contradictions across parallel agent outputs, links sources, and turns everything into one report.
Steps run in order. The output of the previous step becomes the input of the next.
Independent tasks are distributed to different agents at the same time and then merged.
Flow routes to different branches based on the output of a step.
05Memory & Context
Defines how far back an agent can remember. The system uses dynamic context management and RAG to avoid hitting the LLM token limit.
- Keeps only the messages in the active chat session.
- Deleted when the operation ends.
- Added directly to the LLM context window.
- All enterprise documents, past projects, and rules.
- Persistent and stored encrypted.
- The agent retrieves and reads only the part it needs at runtime.
06Guardrails & System Instructions
Guardrails constrain model behavior, while system prompts define the model's role, style, and operating instructions.
system_prompt: |
You are a senior DevOps engineer.
Speak only with confirmed technical evidence.
Never assume. If you do not know, say "I do not know."
# Guardrails (Zero-Trust)
guardrails:
- type: "block_sql_mutation"
action: "Reject DROP, DELETE, UPDATE, and INSERT commands."
- type: "pii_filter"
action: "If output contains email or national ID data, mask it (***)."
07Workspace & Environment Management
Every project lives inside a workspace. A workspace brings agents, tools, connectors, memory pools, and environment variables under one roof. Environments such as dev, staging, and prod run isolated from each other.
environment: production
agents:
- birk-agent-heavy # Orchestrator
- birk-agent-light # Worker agents
connectors:
- type: postgresql
host: ${{DB_HOST}} # From environment variable
- type: slack
webhook: ${{SLACK_WEBHOOK}}
memory:
vector_store: local # or 'managed'
retention: 90d
Fast iteration. Mock connectors and smaller model variants are used.
Real data sources, isolated network. The final validation point before production.
Full isolation, audit logs enabled, guardrails required. Deployed with rollback support.
08Monitoring & Observability
Every agent action, tool call, and model decision is logged in an observable way. End-to-end observability supports enterprise audit, debugging, and performance optimization.
Every pipeline run is stored as a trace, and every agent step as a span. OpenTelemetry compatible.
Who queried what data, when, with which agent - a complete audit trail with immutable records.
Architecture in Essence
A high-level view of how all components work together.