[ early product · looking for 1–3 design partners ]
Your company's AI collaborator. On your infrastructure.
It works with your team in Slack or Teams, reaches the internal tools you allow, and carries durable workflows end to end — from engineering tasks to GTM. Use the best API models available today while the execution environment, the integrations, and the accumulated company knowledge stay under your control.
Early, limited pilots on introductory pricing. One team, one real workflow, jointly agreed security and engineering boundaries.
- execution
- customer Kubernetes
- session store
- customer Postgres
- integrations
- company Git repository
- secrets
- customer secret manager
- model route
- approved API / replaceable
- evidence
- retained by policy
The AI collaborator is more than the model.
The model answers. The system around it works inside your company: it remembers the permitted context, handles permissions, calls internal tools, produces code or documents, waits for approval, and leaves evidence behind.
If that system lives inside a model vendor's product, you pay for intelligence twice: once with money, and once with the company knowledge you must reveal to make it useful. Prompts, tool calls, and above all corrections distill into institutional know-how — and when the learning flows one way, that value accumulates at the vendor, not with you.
The system grows more valuable with use: every new workflow, integration, and lesson makes the next one cheaper. The removal test is simple: if it were taken away tomorrow, what would remain with your company?
Rent the best intelligence. Own the working system.
A large share of employees already use AI tools on their own initiative: in a late-2025 survey of large Hungarian companies, 35% did — while only 14% of the companies had a deployed enterprise AI solution (K&H corporate survey, 2025 Q4).
The durable value stays with the company.
We do not promise that no data ever leaves your network while an external model is in use. What we build is this: the canonical system lives with you, along with the right to decide what is stored, what can be called, and which model may work on a given task.
| Yours to control | What it means in practice |
|---|---|
| Execution environment | Agents run in isolated environments, on infrastructure your company selects and controls. |
| Integrations and workflows | Internal tools, processes, rules, and company extensions are versioned company assets. |
| Canonical operating data | Retained conversations, events, workflow state, and the audit trail can be stored under company control. |
| Secrets and permissions | Real credentials never enter the agent's working environment; their use is tied to explicit grants and purposes. |
| Retention and reuse | The company decides what is kept, for how long, and what may feed retrieval, evaluation, or later training. |
| Evidence for model choice | Models are compared on your own tasks, against quality and cost thresholds you accept. |
When an external model API is used, the requests sent to it fall under that provider agreement. The goal is a controlled, replaceable boundary — not hiding the real data flow.
The same collaborator. Replaceable intelligence.
Your team keeps the same surface, the same integrations, and the same workflows. Behind them, the model that gives the best quality, cost, or data boundary can change per task.
hover the diagram nodes
Technically, switching models can be a new endpoint or model identifier. The business risk is bigger: you must prove the same quality, reliability, and acceptable results. That decision and measurement layer is Legroom.
[ direction · in development ]
The company environment and the dev machine become one continuum.
Legroom and Berek multiply in a pair: a session belongs to a task and moves smoothly between the company's Berek environment and a local machine — start, stop, and hand over on either side, behind the same secrets boundary. A developer can attach to the same sandbox over VS Code or SSH. Legroom keeps the background agents' AI budget efficient; Berek provides the continuity.
We start with one useful workflow.
We do not switch on a "digital employee" with unlimited permissions. We pick one repeated, valuable workflow with clean input, approved tools, human gates, and verifiable output.
From an engineering task to a reviewable change
It understands the task from a Slack or Teams thread, works in the designated repository, runs the checks, and hands over a diff or PR for human review.
From an operational question to an evidence pack
It gathers the facts from approved internal tools and data sources, separates conclusions from sources, and returns the evidence a decision needs.
A durable company workflow
It weaves model calls together with deterministic API calls, waiting, retries, and approval gates. The process survives restarts and stays auditable.
The same pattern works beyond engineering: GTM processes, web surfaces, research, reporting — anything your company would automate with approved tools and human gates.
Give the agent a workspace, not unlimited access.
Every run gets an isolated working environment. The tools and network destinations it needs are defined up front. Long-lived credentials never go into the prompt, files, or the agent environment; the system uses them only for the approved request.
This reduces the blast radius of mistakes and prompt injection, but it does not make the agent infallible. Destructive operations still require narrow permissions, deterministic limits, and human approval.
- ✓ isolated execution environments
- ✓ explicit tool and permission boundaries
- ✓ controlled outbound network access
- ✓ key handling that fits the company's secret manager
- ✓ durable event and audit trail
- ✓ configuration and workflows versioned in Git
From a working internal system to an early enterprise product.
Our internal system runs in its own Kubernetes environment, starts from Slack, works in isolated agent workspaces, connects to repositories and approved tools, and deploys via GitOps. We do not yet call this a finished, general enterprise product.
We are looking for design partners who bring a real workflow, a technical owner, and a clear security boundary — and help prove what can be made repeatable.
| Working in internal use | Proving with design partners | Longer-term direction |
|---|---|---|
| agent platform running on own infrastructure | reproducible enterprise install and handover | standalone, supported product |
| Slack-based shared workspace | a real team using a real workflow | more channels and organizational surfaces |
| isolated execution and GitHub work | customer-specific permissions and integrations | repeatable integration packages |
| external frontier model in use | measured quality, cost, and acceptance | gradual introduction of specialized and self-hosted models |
| GitOps and enterprise secret-handling pattern | customer-side operability | documented support and update model |
Not a chatbot promising unlimited autonomy.
- ✕ We do not claim it solves every company task on its own.
- ✕ We do not ask for unlimited access to every internal system.
- ✕ We do not claim that all data stays inside the network while an external model is in use.
- ✕ We do not promise a cheaper own model until it clears the quality threshold on your workflow.
- ✕ We do not install without evidence, an accountable technical owner, and human approval boundaries.
We install a working delivery system alongside the technology.
An agent platform alone is not an organizational capability. The right first workflow must be chosen, permissions clarified, internal tools connected, cost and outcomes measured, and human review and accountability gates built in.
Berek is made and installed by MI működik — with the same continuous-delivery discipline as its workshops, the AI Delivery Install, forward-deployed engineering, and Legroom: no claim without a receipt.
Let's give it a real job.
It is worth talking when you have a repeated, valuable workflow, an accountable business or engineering sponsor, a technical owner, and a way to judge the result on real evidence.
The first conversation is not a demo pitch. We look at the task, the data flow, the required integrations, the human gates, and the operational responsibility. If there is no narrow, safely provable pilot, we say so.
Ideal first pilot: 1 team · 1 workflow · 1 technical owner · 1 jointly accepted evidence plan
Frequently asked questions
Does all data stay inside the company? +
That is not our claim. The execution environment, the canonical operating state, the integrations, and the retained context can sit under company control. When a task uses an external model API, the request sent there leaves that boundary and falls under the provider agreement. You can decide per task which data and which model route is acceptable.
Which models does it work with? +
The point is not being tied to any single model. A pilot can start with an API model your company already accepts. Later, specialized or self-hosted models can take over tasks where they pass the same evaluation.
Does it require Slack or Teams? +
A shared chat surface is the most natural start, because the team can hand over tasks and receive results in the same workspace. We verify the exact surface and permission model before the pilot.
Does it replace developers or the operations team? +
That is not the product promise. We delegate repeated work, information gathering, and execution steps while responsibility, approval gates, and acceptance stay with the team.
How is it different from a Make- or Zapier-style automation tool? +
Purpose-built tools are faster and cheaper for one or two generic workflows — and in that case we say so: buy the tool. Berek wins where the number and sensitivity of workflows touching internal systems grows: permissions, integrations, and accumulated company context collect in one place, at your company, so each new workflow costs less to start than the previous one. Existing automation tools are not rivals: the collaborator can call them as approved tools.
Where does it run? +
The target is a Kubernetes environment your company controls. During the pilot we jointly settle the deployment, network, secret-management, and operations boundary.
Is it a finished product? +
It is an early product growing out of a working internal system. With the first design partners we prove what can be installed, operated, and handed over repeatably — on introductory pricing, with no general-availability promise.