Skip to content
Eriko AI

Software, built differently.

Eriko combines strategy, engineering and AI-native delivery to take complex ideas from blueprint through to implementation. We use the same approach to build our own products.

See how we build Talk to Eriko
ErikoDelivery / Customer Onboarding / Story 04Human approval required

Story 04 · Customer Onboarding

Identity verification

Outcome: Reduce onboarding completion time · 5 acceptance criteria

  1. Story Architect agentplanning

    Wrote 5 acceptance criteria and split the story into 3 tasks AC1–AC5

  2. Builder agentimplementation

    Added licence upload and details match PR #212

  3. Validation agenttests

    1 check failed: an expired licence was accepted AC2

  4. Builder agentremediation

    Fixed the expiry date check and re-ran the suite 48/48 passed

  5. Reviewer agentindependent review

    Implementation matches AC1–AC5. 2 comments resolved

PLPriya Lal · Product owner

Agent analysis complete. Approve Story 04 for release?

Evidence: 14 records · PR #212 · test run 2Tue 6 Oct, 10:31 AEST
Illustrative interface with sample data
  • Specialised agents
  • Parallel execution
  • Continuous validation
  • Evidence as work happens

How we work

From idea to working system.

Some organisations come to us with a business problem. Others know what they want to build but need the architecture, delivery approach or implementation capability to make it real. We work across that whole journey.

  1. Strategy & Blueprint

    Where the solution takes shape before development begins: understanding the business problem and translating it into something that can actually be built.

    • Technology & solution strategy
    • Data & AI strategy
    • Architecture & platform direction
    • Customer & marketing technology
    • Operating & delivery models
    • Implementable blueprints

  2. Build & Implement

    We design, engineer and implement the solution ourselves. Specialist agents work alongside engineers, coordinated through defined controls, validation and human decision points.

    • Enterprise applications
    • Data & analytics platforms
    • AI-enabled systems
    • Workflow & operational systems
    • Integrations

  3. Products & Platforms

    The same delivery model builds our own products and reusable systems, so the methods, controls and tooling are exercised on software we are accountable for.

    • Own products
    • Reusable systems
    • Lessons back into client delivery

One AI-native delivery system runs through all three.

How we build differently

We have rebuilt the software development lifecycle around what AI agents can now do.

The common pattern

An AI coding assistant

One tool helps one person work faster. The hand-offs between stages stay where they were.

The Eriko model

A lifecycle redesigned around agents

Different agents take responsibility for different parts of the work within defined boundaries. Work runs concurrently wherever dependencies and risk allow.

Agents can take meaningful responsibility across the engineering lifecycle.

  • PlanRequirements interpretation
  • PlanWork decomposition
  • PlanPlanning
  • BuildImplementation
  • AssureTesting
  • AssureCode review
  • AssureValidation
  • BuildRemediation
  • RecordDocumentation
  • RecordEvidence

Checks run as the result is produced. Failures feed straight into controlled remediation loops, and evidence of what was built, tested and reviewed accumulates as part of delivery.

People remain responsible for product direction, architecture, risk, exceptions, acceptance and release. The aim is to reduce the manual coordination it takes to turn an idea into reliable working software.

Our position

Useful autonomy comes from control, not access.

The common assumption is that AI systems become more useful the more freedom they are given. In practice the opposite holds.

Widening access without those things produces more output and less certainty.

We design for the limits first. It is the less exciting half of the problem, and it is the half that decides whether any of this can be trusted with work that matters.

Four responsibilities make the work dependable.

Taken apart these are familiar ideas. Built into the development process as one system, they change how much of the engineering lifecycle can run without manual intervention.

Control

What is allowed?

Control sets the boundary: what an agent may act on, what it may spend, and which decisions have to come back to a person. Permissions do not widen just because a task is already running.

Orchestration

What happens next?

Orchestration carries work between agents, people and systems, runs independent work in parallel, pauses it when a dependency changes, and makes delays and pending decisions visible.

Evidence

Why trust the result?

The checks, versions, failures and decisions are recorded as the work happens, so a reviewer can judge a result instead of reconstructing it from a conversation.

Human authority

Who is accountable?

The people who own the outcome keep product direction, architecture, risk, acceptance and release. Agents do not approve their own work, and automated progress never quietly becomes permission.

The delivery system

A continuous engineering model.

Traditional delivery is a series of human hand-offs, with work moving backwards and forwards until it is ready to release. In our model, AI is part of how work is planned, executed, checked and evidenced from the start.

  1. 01Business outcome
  2. 02Planning
  3. 03Specialist agents
  4. 04Orchestration
  5. 05Controls and human decisions
  6. 06Continuous validation
  7. 07Evidence
  8. 08Delivered outcome

Failures at validation feed back into controlled remediation, not another manual cycle.

01–02

Intent

Work starts from the outcome that has to be delivered.

Planning decomposes the requirement into work agents can execute reliably, with scope, limits and success made explicit. The method can change as the team learns; what counts as success cannot change quietly.

03–05

Execution

Different agents own different parts of the engineering work.

Independent work proceeds concurrently where dependencies allow. Agents continue through defined engineering loops without a person initiating every step, while approvals sit inside execution rather than after it.

06–07

Assurance

Testing and deterministic validation run throughout the work.

The agent responsible for implementation is not the one that decides whether the result is correct. Failures feed into controlled remediation, and evidence of what was checked accumulates as work proceeds.

08

Outcome

Working software, together with the record of how it was built, tested and reviewed.

Most of the time saved comes from removing the manual hand-offs and pauses that sit between every stage of a conventional lifecycle.

Products

One method. Different software.

We use the same approach on our own software as on client work. The software is different in each case. The approach to execution, validation and control stays the same.

Production SaaS · Regulated care

Auditly

Operational compliance and quality management software for regulated service organisations, covering quality management, incident management, policy management, identity and access, analytics and wider platform work.

Delivery combines structured requirements, agent execution, automated testing, independent review and controlled promotion through development, QA and production.

The model operates inside a substantial production SaaS platform where reliability, security, data integrity and controlled change matter.

ErikoDelivery / Auditly / Release 4.12In QA

Auditly · Release 4.12

Incident and policy updates

Development4 of 4 merged · 2 Oct
QA3 of 4 passed · now
ProductionRelease manager approval
StoryTitleAgentChecksStatus
AUD-311Filter incident register by severity62/62Passed
AUD-318Policy acknowledgement reminders41/41Passed
AUD-322Site-scoped access for site leads37/38Changes requested
AUD-326Export incident trends to CSV29/29Passed

Reviewer agenton AUD-322

Site leads can see incidents from other sites when they filter by date. Add the site scope to the date query and a test that covers it.

Returned to Builder agent · blocks promotion to Production
Illustrative interface with sample data

Governed agentic system · Delivery

Story Architect

A governed agentic system that turns business intent into structured, validated delivery work, using explicit validation rules, evidence generation, independent review and integration into development workflows.

It is becoming part of the wider delivery system, improving the transition from intent into work agents can execute reliably.

Here the methodology itself becomes software, so it no longer depends on the people applying it.

Story ArchitectCustomer Onboarding / Story 04Ready for review

Business intent

Reduce onboarding completion time from 5 days to same day.

PLPriya Lal · Product owner
  • 01Account details form
  • 02Email verification
  • 03Document upload
  • 04Identity verification
  • 05Welcome sequence

Story 04 · User story

As a new customer, I want to verify my identity online, so I can start using my account the same day.

Acceptance criteria

  1. AC1Given a current driver licence, when the details match, then the account is verified.
  2. AC2Given an expired licence, then verification is declined with the reason shown.
  3. AC3Given three failed attempts, then the case moves to manual review.
TestableDepends on Story 03Within scopeIndependent review
Story Architect agent · analysis complete · Mon 5 Oct, 14:20
Illustrative interface with sample data

Built the same way

Three more applications

Events & venues

Event management platform

A guest invitation use case that expanded quickly into event and venue management: RSVP workflows, table and capacity management, seating allocation and a visual seating planner.

It shows how far the development cycle compresses when agents, context, validation and controls operate together from the start.

Media engineering

Encore

Audio analysis and processing, timing, transitions, loudness management and automated mix generation, built with separate implementation and review responsibilities.

The approach extends well beyond web applications and business SaaS into specialised computational engineering.

Real-time multiplayer

Category Game

A consumer application built with separate builder, reviewer and validation responsibilities, including browser, multiplayer lifecycle and accessibility testing.

The model applies to interactive consumer software, where real-time behaviour and experience decide whether it is any good.

The harder problem moves from generating work to controlling it.

As more of the engineering lifecycle runs on its own, we are building the operating layer for managing work, agents, validation, evidence and delivery controls. Other Eriko products, including KontextGo and Salaamah, are built the same way.

Why organisations work with Eriko.

Advice that ends in working software

We design, engineer and implement the systems we recommend rather than stopping at a strategy document.

Governed by design

Controls, approvals and accountability are built into how the work executes from the first step.

Proven on our own products

The delivery model is exercised through real product development, so it is tested on software we are accountable for.

Evidence as work happens

Validation, decisions and delivery evidence are captured during execution, so they are ready when a review needs them.

About Eriko

We work in the space between what AI can demonstrably do and what an organisation can actually put its name to.

Eriko AI combines enterprise technology experience with hands-on development of the delivery systems we use to build software. The work is practical: systems that run, controls that hold under pressure, and results that can be accounted for.

More about Eriko

Founder

Sabeh Hassan, Founder and CEO of Eriko AI

Sabeh Hassan

Founder & CEO

If AI can now perform a significant proportion of the work involved in software engineering, why should the development process around it remain largely unchanged?

Eriko grew from that recurring question. Sabeh has spent his career across technology, consulting, data, transformation and product development, from large enterprise transformation programs to building products and businesses from the ground up.

  • Microsoft
  • Deloitte
  • DXC
  • Executive MBA, AGSM at UNSW
More about Sabeh

What could your delivery model look like if AI was part of the operating system?

If that question is already live in your organisation, we would be glad to talk about where it leads.

Talk to Eriko See the delivery system