SYSTIQOApplied AI & Systems Lab
Our Work

What we have built, labelled for what it is

Every item here carries its evidence type: a system we engineered and run ourselves, a reference architecture we publish in detail, or research we have written up. No client case studies are published yet, and nothing on this page is presented as one.

Read this ifyou want evidence a team can engineer the system, not a list of the technologies it has heard of.

01Internal Builds

Systems we engineered and run ourselves

Written up the way we would write up client work: the problem, the system, the architecture decisions and what they cost.

Internal buildDeployed on systiqo.com

Enquiry intake and screening pipeline

Problem
A business enquiry form has two jobs that pull against each other: never lose a genuine enquiry, and keep bulk outreach and bots out of an inbox a person reads line by line.
Context
SYSTIQO's own website. Enquiries come from decision-makers describing a business problem in their own words, often without a technical brief, alongside the automated traffic every public form attracts.
System
A multi-step form that captures the problem in business terms, and a server-side pipeline that validates, screens, delivers and confirms every submission.
Engineering challenge
Deciding which failures are allowed to cost a lead. Every layer that could block a genuine enquiry, from a classifier outage to a bounced confirmation, was designed to degrade toward delivery rather than rejection.
Outcome
Deployed as the enquiry path on this site. The field rules, spam signals and email rendering are covered by automated tests.

Architecture decisions

  • One set of field rules shared by the browser and the server, so a form step can never accept what the server later rejects.
  • Layered screening: automated-submission checks, then deterministic text signals, then an optional AI classifier. Signals are attached for a person to judge rather than used to silently discard a lead.
  • The AI step fails open. A timeout, an outage or an unexpected answer lets the enquiry through, because a missed spam message costs less than a lost client.
  • Visitor text reaches the model as delimited, untrusted input, and the verdict can only ever add a label to an email. A prompt injection gains nothing beyond mislabelling its own message.
  • Delivery through a transactional email API with idempotency keys derived from the submission, so a network retry cannot send the same enquiry twice.
  • Failures are ranked. Only a failed delivery to SYSTIQO is reported to the visitor; a failed confirmation email is logged instead, because the enquiry itself was not lost.
  • Personal data stays out of URLs: the confirmation page reads the visitor's first name from a short-lived cookie, not the query string.

Technology

  • Next.js Server Actions
  • TypeScript
  • Resend
  • Vercel AI SDK
  • Claude Haiku
  • Node.js test runner
02Reference Architectures

How we structure the systems we build

Each one is published layer by layer on its capability page. These are design positions, not delivered projects: they show how we would approach the system before anyone asks us to.

Applied AI

AI system stack

Problem.
A model that works in a demo is not yet a system a business can rely on.
System.
Ten layers around the model: what it is given, what it may do, how its output is grounded, evaluated and monitored.
Designed for.
AI behaviour that is defined, checked and observable in production.
Explore the architecture
AI Agents & Copilots

Agent architecture

Problem.
An agent that can call tools can also call the wrong one, with real consequences.
System.
Ten components between the model and the user, including tool permissions, context, memory, review points and escalation.
Designed for.
Agents that act within defined authority, with a person in the loop where the consequence warrants it.
Explore the architecture
Intelligent Automation

Workflow architecture

Problem.
A trigger and a sequence of actions is easy to build. Month six, when a connected system changes or a record arrives half-complete, is not.
System.
Eleven concerns a running workflow meets, in the order a single run meets them: state, exceptions, approvals and recovery among them.
Designed for.
Workflows that stay trustworthy as connected systems and people change.
Explore the architecture
Data & Intelligence

Data system architecture

Problem.
Intelligence is only as reliable as the data layers underneath it.
System.
Ingestion, transformation, storage, retrieval, access, evaluation and monitoring designed as one foundation.
Designed for.
Decisions and AI systems that read from data a team can trust.
Explore the architecture
Connected Systems & Integration

Integration architecture

Problem.
Point-to-point connections create a new dependency problem for every one they solve.
System.
Ownership, contracts, transformations, failure behaviour and observability defined for each connection.
Designed for.
Separate systems that behave as one environment, including when one of them is unavailable.
Explore the architecture
Cloud & Infrastructure

Infrastructure architecture

Problem.
Every infrastructure layer has a failure mode, and failures compound across layers.
System.
Application architecture, deployment, networking, security, observability and recovery designed together.
Designed for.
Systems that can be operated, watched and recovered once they leave engineering.
Explore the architecture
Security & AI Governance

Security architecture for intelligent systems

Problem.
Security reviewed just before launch is security added to a design that never accounted for it.
System.
Controls placed along the path a request takes through the system, from identity and access to data handling, model controls and audit.
Designed for.
Systems whose access, actions and history can be defined and proven.
Explore the architecture
03Research Write-ups

The thinking behind the systems

Write-ups from the open questions in our Research Lab: where AI projects stall, how workflows fail partway, and how to tell whether retrieval is actually working.

Every question still open, published or not, is listed on the Research Lab page.

04Client Work

No client case studies are published yet

We would rather say so than present a prototype as a client project. Client work appears here only with the client's written approval, and it will carry the same fields as the build above.

  • Problem
  • Context
  • System
  • Architecture
  • Technology
  • Engineering challenge
  • Outcome
05Next Step

Have a system worth engineering properly?

Describe the problem it has to solve. We will tell you how we would approach it, what we would need to learn first, and whether it is worth building now.

Discuss Your System
WhatsApp
  1. Problem
  2. Research
  3. Architecture
  4. Engineering
  5. Outcome

What happens next

  1. A person reads itNot an autoresponder and not a sales queue: an engineer who can tell whether we're the right people for this.
  2. We reply within one business dayUsually sooner. If we're not a fit, we'll say so and point you somewhere better.
  3. A 30-minute first callAbout your problem. No pitch deck, no obligation, nothing to prepare.
Start a conversationLet's talk