NeuralSharks
Start a Project

NEURALSHARKS LABS

We build to understand what’s next.

Labs is where we test emerging technology by building with it: AI prototypes, automation experiments, developer tools, and the research behind them.

Every experiment starts with a real problem and a question worth answering. Each one records what we tried, what we used, and what we learned, and links to a demo, code, or write-up only once one exists.

Explore the experiments How Labs works

WHAT WE BUILD HERE

  • 01AI prototypes
  • 02Automation experiments
  • 03Developer tools
  • 04Open-source projects
  • 05Engineering experiments
  • 06Internal products
  • 07Technical research

01 / EXPERIMENTS

Problems we want to understand.

Each experiment names the problem, the approach we are testing, and the technology involved. These are the first experiments on our list; we will build them one at a time, and each card will change as the work does.

FILTER BY TRACK

Showing 8 of 8 experiments

  1. NSL-001AI prototypes

    Stage: Concept

    FIG. 001 / SCHEMATICIllustrates the design. Not a screenshot.

    AI document intelligence

    Extracting structured, verifiable fields from messy business documents.

    PROBLEM
    Invoices, contracts, and forms arrive in inconsistent layouts. Teams re-key the same fields by hand, and a wrong value can travel silently into downstream systems.
    EXPERIMENT
    Combine layout-aware parsing with a language model that returns typed fields, each with a link back to its source region and a confidence signal, then route uncertain fields to a person.
    TECHNOLOGY · PLANNED
    • Python
    • OCR and layout parsing
    • LLM structured output
    • PostgreSQL
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which fields can be extracted reliably without human review?
    2. Q2Does citing the source region measurably speed up human checks?
    3. Q3Where do schema validation and model judgement each belong?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI developmentAI automationData & integrations

  2. NSL-002Technical research

    Stage: Concept

    FIG. 002 / SCHEMATICIllustrates the design. Not a screenshot.

    RAG playground

    Comparing retrieval strategies side by side against the same evaluation set.

    PROBLEM
    Retrieval choices, such as chunking, embeddings, hybrid search, and re-ranking, change answer quality, but they are often picked by intuition and never compared.
    EXPERIMENT
    A workbench that runs one question set through interchangeable retrieval pipelines and records which sources were retrieved, whether the answer was grounded, and what each run cost.
    TECHNOLOGY · PLANNED
    • TypeScript
    • Next.js
    • Vector databases
    • RAG pipelines
    • Evaluation harness
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1How much do chunking decisions matter compared with the choice of embedding model?
    2. Q2When does hybrid search earn its added complexity?
    3. Q3Which grounding checks catch failures that people actually care about?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI developmentAI agentsData & integrations

  3. NSL-003AI prototypes

    Stage: Concept

    FIG. 003 / SCHEMATICIllustrates the design. Not a screenshot.

    AI support agent

    A bounded support agent that knows when to hand over to a person.

    PROBLEM
    Support assistants either answer only from a static FAQ or act with too much freedom. Neither is safe once an agent can look up orders or change accounts.
    EXPERIMENT
    An agent with explicitly scoped tools, read-only by default, that drafts replies, cites its sources, and requires human approval before any consequential action.
    TECHNOLOGY · PLANNED
    • TypeScript
    • Node.js
    • Tool calling
    • Knowledge base retrieval
    • Audit log
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which permission model stays understandable to operators?
    2. Q2How should the agent express uncertainty to a customer?
    3. Q3What does a useful handover to a human include?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI agentsAI automationWeb development

  4. NSL-004Engineering experiments

    Stage: Concept

    FIG. 004 / SCHEMATICIllustrates the design. Not a screenshot.

    Voice agent

    Holding a natural spoken conversation inside a strict latency budget.

    PROBLEM
    Voice interfaces feel broken when replies lag or when the agent talks over the caller. Each stage of the pipeline adds delay, and the delays compound.
    EXPERIMENT
    A streaming speech-to-text, model, and text-to-speech pipeline with a latency budget for each stage, interruption handling, and a fallback when a stage misses its budget.
    TECHNOLOGY · PLANNED
    • Python
    • WebRTC
    • Streaming speech-to-text
    • Text-to-speech
    • Observability
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which stage dominates end-to-end latency in practice?
    2. Q2How should the agent recover when a caller interrupts it?
    3. Q3What is the simplest dependable way to hand a call to a person?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI developmentAI agentsCloud & DevOps

  5. NSL-005Automation experiments

    Stage: Concept

    FIG. 005 / SCHEMATICIllustrates the design. Not a screenshot.

    Workflow automation engine

    Observable automation with replayable events and operator controls.

    PROBLEM
    Automations fail quietly. A timeout, a duplicate event, or a missing field leaves work half done, and nobody can see where or why.
    EXPERIMENT
    A small engine where every step is recorded as an event, with idempotent retries, a dead-letter queue, and controls to pause, inspect, and replay a single run.
    TECHNOLOGY · PLANNED
    • TypeScript
    • NestJS
    • PostgreSQL
    • Redis
    • Docker
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which recovery controls do operators actually reach for?
    2. Q2What is the smallest event model that still supports replay?
    3. Q3Where should AI steps sit relative to deterministic rules?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI automationCustom software developmentCloud & DevOpsData & integrations

  6. NSL-006Technical research

    Stage: Concept

    FIG. 006 / SCHEMATICIllustrates the design. Not a screenshot.

    Computer vision experiment

    Testing where on-device vision is good enough, and where it is not.

    PROBLEM
    Visual inspection and counting tasks are repetitive, but it is rarely clear whether a model can run on a phone or needs a server, or how it fails under real lighting.
    EXPERIMENT
    Run the same detection task on-device and server-side, with a deliberately varied image set, and compare accuracy, speed, and failure modes.
    TECHNOLOGY · PLANNED
    • Python
    • Object detection models
    • React Native
    • On-device inference
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1How large is the accuracy gap between on-device and server-side models?
    2. Q2Which conditions cause the most failures?
    3. Q3How should uncertain detections be presented to a person?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDAI developmentMobile app development

  7. NSL-007Internal products

    Stage: Concept

    FIG. 007 / SCHEMATICIllustrates the design. Not a screenshot.

    Testing dashboard

    One view of test health across suites, builds, and flaky checks.

    PROBLEM
    Test results are scattered across pipelines. Flaky tests erode trust in the suite, and slow ones are hard to spot until a release is blocked.
    EXPERIMENT
    An internal dashboard that collects results from every pipeline run, tracks each test over time, and flags flaky, slow, or newly failing checks.
    TECHNOLOGY · PLANNED
    • TypeScript
    • Next.js
    • Playwright reports
    • JUnit XML
    • PostgreSQL
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which signals predict that a test is flaky rather than broken?
    2. Q2What should block a release, and what should only warn?
    3. Q3How much history is needed before trends become useful?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDSoftware testingTest automationCloud & DevOps

  8. NSL-008Developer tools

    Stage: Concept

    FIG. 008 / SCHEMATICIllustrates the design. Not a screenshot.

    API performance visualizer

    Seeing latency distributions instead of averages.

    PROBLEM
    Average response times hide the slow requests users feel. Percentiles are reported as single numbers, and regressions slip through between releases.
    EXPERIMENT
    A developer tool that turns traces and load-test output into latency distributions per endpoint, and compares them across builds to highlight regressions.
    TECHNOLOGY · PLANNED
    • TypeScript
    • OpenTelemetry
    • Load testing
    • Data visualization
    WHAT WE LEARNED

    Not run yet. Findings will be published here, including what didn’t work.

    Questions it is designed to answer

    1. Q1Which views make tail latency obvious at a glance?
    2. Q2How should a regression be defined, so that real slowdowns are flagged without false alarms?
    3. Q3Can it be useful from a single trace file, with no setup?
    • Live demoNot built yet
    • GitHubNot public yet
    • Technical articleNot written yet

    RELATEDCustom software developmentWeb developmentSoftware testingCloud & DevOps

All experiments are currently at the concept stage. Schematics illustrate each design; they are not screenshots or output. Demo, GitHub, and article links are added only when a working build, a public repository, or a published write-up exists.

02 / LAB PROTOCOL

How an experiment earns a link.

Labs is only useful if it is honest. Every experiment moves through the same four stages, and each stage changes what we are willing to show.

  1. Concept

    The problem and the experiment are defined. Nothing is built yet.

    08 experiments

  2. Building

    Work is under way. Nothing is public until it runs end to end.

    00 experiments

  3. Prototype

    A working build exists. A live demo appears only if it is deployed.

    00 experiments

  4. Released

    Published as a product, an open-source repository, or a write-up.

    00 experiments

  1. 01

    No fake demos

    A live demo link appears only when a working build is deployed and you can use it. No mock-ups, screen recordings, or staged screenshots presented as a product.

  2. 02

    We publish what we learn

    When an experiment runs, its findings are written up here, including what did not work. Until then, each card lists the questions it is designed to answer.

  3. 03

    Experiments graduate

    Some become internal products or open-source repositories. Others become the practices we bring to client work. Some end, and we say why.

FROM LAB TO PRODUCTION

Seen a problem worth testing?
Let’s build it for real.

The questions we explore in Labs are the ones our clients face in production. If one of these experiments looks like your problem, we would like to hear about it.

Start a Projectsharksneural@gmail.com