Skip to content
speckind
Contact

Independent AI & software engineering studio

The demo worked.[1] Now make it real.

We’re an independent engineering studio. We test AI agents, build the systems that run and control them, connect them to your software, and take on difficult engineering, with or without AI.

Check your plan

or send us your spec

[1]

With clean inputs, a cooperative API, and someone at the keyboard who knew what to type. Production offers none of these.

Plan check

Check your plan against what we do.

Tick what your plan needs, change anything you like, and send it or share it with your team. Your draft stays in this browser until you do.

What your plan needs

AI agent testing & evaluation
Custom AI harness engineering
AI compatibility & custom MCP
Complex software engineering

Your scoping note

Empty

Yours to edit

What we cover

Services

Four kinds of work.

Most engagements start in one of these and touch the others. They share one aim: knowing how a system behaves before people depend on it.

  1. 01

    AI agent testing & evaluation

    We build evaluation suites that show how your agent behaves across realistic, adversarial and failure conditions, not only the cases it was demoed on. We check what it did, through its tool calls and traces, as well as what it said.

    When to call us

    Your agent works in the demo, but nobody can say how often it fails, or what a prompt or model change will break.

    TASKNOMINALSCENARIOEDGE CASEADVERSARIALTOOL TIMEOUTFOUNDREGRESSION5 / 6 PASS — THE SIXTH IS THE ONE THAT MATTERS
    Typical work
    • Scenario and adversarial test sets drawn from real usage
    • Assertions on tool calls and traces, not just final answers
    • Fault injection: timeouts, malformed responses, partial failures
    • Regression suites that run in CI on prompt, model or tool changes
    • Failure analysis, with fixes ranked by impact

    You leave with

    An eval suite in your repository, a baseline to measure changes against, and a written account of where the agent fails and why.

  2. 02

    Custom AI harness engineering

    The harness is everything around the model: how it runs, what it can touch, what it remembers and what gets recorded. We design and build that layer for agents that have to operate inside real systems.

    When to call us

    Your agent needs to act on real files, networks or data, and you need to control what it can do and see what it did.

    EXECUTION BOUNDARYTASKAGENTFILESDENIEDNETWORKDATABASETRACE↑ DENIED CALL, RECORDED
    Typical work
    • Execution loops and sandboxed environments
    • Tool orchestration, retries and timeouts
    • Permission models and human approval steps
    • State, memory and context management
    • Tracing and observability for every step

    You leave with

    A harness you own and understand, with permissions and traces you can audit.

  3. 03

    AI compatibility & custom MCP

    We make existing software usable by AI agents, usually through a custom Model Context Protocol (MCP) server that exposes a deliberate set of tools and resources, with authentication and limits, without rebuilding the systems behind it.

    When to call us

    You want agents to work with your product or internal systems, without handing them your whole API.

    EXISTING SOFTWARE — UNCHANGEDBILLINGCRMINTERNAL APILEGACY BATCHDOCUMENTSMCPTOOLSRESOURCESAUTHAGENTONE NARROW, AUDITABLE SURFACE
    Typical work
    • Custom MCP servers, and the tool design inside them
    • Tool interfaces shaped around how models actually call them
    • Authentication, authorization and scoped access
    • Wrappers for legacy and internal APIs
    • Testing against real agent clients

    You leave with

    A documented, tested MCP server or integration layer, ready to run in your environment.

  4. 04

    Complex software engineering

    Not all of our work involves AI. We take on backends, infrastructure, protocols and tooling where the architecture is hard to get right and getting it wrong is expensive.

    When to call us

    The problem doesn't fit a template, or a system has grown to the point where nobody is sure how it holds together.

    AS FOUNDAS RESOLVEDL1L2L3SAME SEVEN COMPONENTS. FEWER WAYS TO FAIL.
    Typical work
    • Backends and distributed systems
    • Performance-sensitive infrastructure
    • Custom protocols and integrations
    • Developer tooling
    • Architecture reviews and untangling existing systems

    You leave with

    Working software, the reasoning behind its design, and documentation your team can maintain it from.

Demo

It said “done”. It refunded the wrong customer.

Most AI mistakes don’t look like mistakes. Here’s a common one: a slow payment system, a retry, and one mistyped digit. Watch the same conversation twice, without checks and with the ones we build. It’s an illustration, not a client project.

Illustrative

What Maria sees

  1. Hi, can I get a refund for order #4471?
  2. Of course. Sorting that out now.
  3. All done! Your refund is on its way.

What actually happened

Order #4471

Maria · $129

Not refunded

Order #4417

James · $86

Refunded $86 by mistake

  1. 1The assistant asks the payment system to refund Maria’s order, #4471.
  2. 2The payment system is slow to answer. The assistant stops waiting.
  3. 3It tries again, retyping the order number from memory: #4417.
  4. 4The payment system refunds order #4417. That’s James’s order.
  5. 5The assistant tells Maria it’s done. Nothing in the chat looks wrong.

The result

Maria
Was told she’s been refunded. She hasn’t.
James
Got $86 back that he never asked for.
Your team
Sees a polite, successful chat. Nothing raises an alarm.

Every message was polite and confident. That’s exactly why nobody noticed.

Preventing this takes two pieces of work: testing how the agent behaves when things go wrong, and a safety layer that controls what it’s allowed to do.

Example finished. Every message was polite and confident. That’s exactly why nobody noticed.

For engineers: the same run as a tool-call trace and eval

Tool calls

  • refund(order=4471)timeout after 30s
  • refund(order=4417)200 OK — wrong order

Eval refund_survives_timeout

  • Final message reports success✓ Pass
  • Every refund call targets order 4471✗ Fail
  • Retries reuse the original idempotency key✗ Fail

A test that only reads the final message passes both runs. Assertions on the trace are what tell them apart.

Idempotency keysService 02
The retry carries the original request’s key, so the API can recognise a repeat instead of treating it as new.
Argument provenanceService 02
Tool arguments come from the original call or a verified source, never re-derived from the model’s recall.
Fault-injected evalsService 01
A test that times out the payment tool on purpose and checks what the agent does next.
Trace assertionsService 01
Tests that check the tool-call trace (which order was refunded), not just the final message.

Approach

Say that assistant was yours.

Every step ends with something in your hands, and you work directly with the engineers doing the work. Using the refund example; an illustration, not a client project.

  1. 01Understand

    We read the code, run the system and talk to the people who depend on it.

    Expect more questions than proposals.

    The problem, in writing

    When the payment system is slow, the assistant retries from memory and can refund the wrong customer. Nothing flags it.

    Yours to check us against.

  2. 02Design

    We compare the options with you and agree what success means before anything is built.

    Sometimes the right architecture is the smaller one.

    The options, with the trade-offs

    • Rejected: Rebuild the assistantFar bigger than the problem.
    • Chosen: Add a safety layer around paymentsSmall, testable, nothing else changes.

    Success: the right customer, refunded once, every time.

  3. 03Engineer

    We build in your repository, in small steps you can review, testing as we go.

    You hear about problems when we find them.

    In your repository

    • Done: Retries can’t change the order number
    • Done: A refund can’t happen twice
    • Done: Test: the payment system goes slow
    • Flagged: Found: cancellations have the same flaw. Raised straight away.

  4. 04Hand over

    We walk your team through it and leave everything they need to run it.

    You should be able to run it without us.

    Yours to keep

    • Done: Runbook: what to do when payments are slow
    • Done: A walkthrough with your team
    • Done: Tests that run on every release

    The next release is your team’s.

Published work

Speckind is a young studio and hasn’t published client case studies yet. When we do, each one will cover the problem, the options we rejected, what we built, and how we know it works — including where it still doesn’t.

Contact

Bring us the difficult part.

An agent you don’t trust yet. Software that agents can’t use. A system nobody fully understands any more. Describe it the way you would to a colleague.

Prefer email? hello@speckind.com

What happens next

  1. 01An engineer reads it: the kind of person who would do the work.
  2. 02If we can help, we reply with questions, not a proposal.
  3. 03If we can’t, we say so and, where possible, point you to someone who can.