Services
AI and process automation
Automation of repetitive processes, integrations with language models, agent tooling built on the Model Context Protocol, and data collection for reporting.
- Who it is for
- Teams with a repeatable process to take off their hands
- Scope
- Automation, model integrations, agent tooling
- Outcome
- Model output checked by a gate
- Principle
- The model answers, a person decides
What the work covers
Measurement before automation
How many times a month, how long one run takes, what unusual data does.
Language model integration
Working the API, designing context, handling errors and controlling cost.
Agent tooling on MCP
A narrow scope, explicit permissions and a gate that halts the work.
Classification and extraction
Tickets, fields pulled from documents and a drafted first response.
Data collection for reports
Scheduled jobs from APIs, databases and pages into one place.
Data correctness checks
A missing field or a duplicate stops the run.
Traffic analytics
Google Analytics 4 and Search Console with consent configured.
Judging low-code
Which process can stay no-code and which needs its own application.
Where an AI project starts
An AI-based project starts with the question of what needs to improve and how to measure it, not with choosing a model. Only afterwards does the work move down to integration, prompts and how results get evaluated.
Integrating a language model means working with its API, designing the context, handling errors and controlling the cost of requests. The output gets treated as input to be checked, not as a finished answer.
How agent tooling gets built
Agent tooling gets built around the Model Context Protocol. An agent gets a narrow scope, explicit permissions and a gate that halts the work when the result fails a condition.
Automation starts with measurement, not with a tool. How many times a month someone performs a given task, how long one run takes and what happens when the data is unusual. The cheapest automation is often a plain script run on a schedule and wired into an existing API. A robot clicking through an interface is left as a last resort, because it breaks with every screen change.
Data, reports and the low-code boundary
A language model steps in where the data is unstructured: classifying tickets, extracting fields from documents, drafting a first response. The model answers, a person decides. A failed run lands in a queue for manual review instead of disappearing without a trace.
Data lands in one place from APIs, databases and web pages through scheduled jobs, and a test guards correctness, not good intentions. A missing field or a duplicate stops the run instead of quietly entering a report.
Low-code works well for a prototype and a simple internal process. The cost grows with the number of exceptions and licences. The business logic ends up locked inside a tool it is hard to move away from. Which process can stay no-code is judged case by case, and the exit gets managed without interrupting a team.
Tools and standards
- Anthropic API
- OpenAI API
- Model Context Protocol
- Python
- TypeScript
- Node.js
- Cloudflare Workers
- Cloudflare D1
- GitHub Actions
- SQL
- Google Analytics 4
- Google Search Console
Proof: the same gate in our own CI
The gate that halts an agent is the same rule that guards the contract in our own CI.
- Agent scope
- Narrow, with explicit permissions
- The rule
- A gate halts the work when a condition fails
- Analytics
- Google Analytics 4 and Search Console with consent
The same pattern guards the contract in the CI of our other projects. Analytics consent is configured exactly the way it is configured on this site.
What changes once it is in place
- Less manual work in the repeatable steps of a process
- Model output checked by a gate, not taken on faith
- Request cost and limits calculated before deployment
- Data errors stop the run instead of landing in a report
- A calculated threshold beyond which a no-code tool stops paying for itself
- A solution a small team can actually maintain
Typical use cases
- An assistant answering questions about product documentation
- An MCP server exposing company data to agent tooling
- Initial classification of tickets before a person handles them
- Scheduled data collection from external sources into a single dashboard
- A review of queries and positions in search results
- An exit from a low-code tool after the number of users grows
Questions that come up most often
Where does an AI-based project start?
With the question of what needs to improve and how to measure it, not with choosing a model. Only afterwards does the work move to integration, prompts and evaluation.
What happens to the model output?
It gets treated as input to be checked, not as a finished answer. The model answers, a person decides, and a failed run lands in a queue for manual review.
How are agent permissions limited?
An agent gets a narrow scope, explicit permissions and a gate that halts the work when the result fails a condition. The tooling is built around the Model Context Protocol.
When is a plain script enough instead of a model?
The cheapest automation is often a script run on a schedule and wired into an existing API. A language model steps in where the data is unstructured.
When does a low-code tool stop being enough?
The cost grows with the number of exceptions and licences. The business logic ends up locked inside a tool it is hard to move away from. The exit gets managed without interrupting a team.