A deep dive into the past 2 months at Amygda, and building AutonomousAI stack (Week 63)

Yep, it’s been 9 weeks between my previous update and this one. What was meant to be a weekly update became a monthly update, and I didn’t realise when it veered off into long breaks between updates.

I guess, that gives you a better idea than anything I can say or write about how busy it is at Amygda. And we are ready

A note on being busy

A couple of years ago I watched a TED talk on how ER doctors triage an always busy schedule.

And since then I’ve stopped saying I or we as a team are busy. Everyone is busy, everywhere.

What will stand you out from others in challenging, chaotic times, is whether you are ready for it or not.

How does that affect building a startup?

That mindset change is important.

In the early days of a project, you won’t know all the answers (at least we don’t). And it can be easy to say let’s write down all the scenarios and build for them.

I don’t like that approach. At an early stage, speed is your friend.

I often say, we will be burnt on this one and we will solve it then. Because I have the balls to know that even if everything was on fire as a team we will come through it.

We are ready.

So whether you are thinking of a start-up, or even otherwise try to remove the word “busy” from your vocabulary. It doesn’t actually get any point across – in fact it’s a lazy answer in my eyes.

OK, can we get back to Amygda?

Yes, we should.

We have continued to build the Complex Event Processing (CEP) system for high-frequency streaming analytics.

In the last 3 months, we have done two proof of concepts on two different industries.

We were able to deliver one proof of concept in 2 weeks. It takes 3 to 6 months to set up a working proof of concept with a scalable CEP system.

We do our proof of concept by giving customers access to the actual product. We don’t just produce reports or presentations. But rather a usable product.

You can imagine, the effort we’ve put in to have something which can be productionised in 2 weeks.

That has worked because we built the architecture for doing high-frequency analytics from the ground up. We could find efficiencies in productionisation that a lot of products that don’t begin with a product-first mindset could never find.

Product aside, what’s the progress on data science ?

Part of the 2-month silence has been that there’s a lot ongoing. Data science practice adds heavily to the product.

One of the challenges we find is that industrial time-series data doesn’t lend itself nicely to the ML methods where labelled data and frequency of data matters a lot.

For example, products like Datadog, H2O.ai, or any other Auto-ML product does a good job once the problem is set up.

Problem set-up includes:

  • data quality checks
  • labelling data (accounting for human error, interrogating the source of truth DB, etc)
  • creating features (including normalisation methods not driven from thermodynamics, etc)
  • selecting right features

Once this is in place, existing Auto-ML can do a good job. But in the industrial domain that doesn’t happen.

This is why we are putting a lot of effort into our own Autonomous AI stack.

What is Autonomous AI?

It’s our stack that is built for unsupervised application to data.

Humans drive a lot of knowledge in how potential damage or inefficiency in equipment can be detected.

This accounts for capturing known-known issues. However, at a higher frequency of data availability, the sheer volume of data to churn through is huge. And analytics built for a lower frequency of data don’t work well.

When you have to select from 10 features, manually that could work.

When you have to select from 600+ features, you have to learn more on hyperparameter tuning or hyperparameter selection. Amongst others.

Autonomous AI enables Amygda to do that rapidly.

Another challenge in the industrial domain is that historically maintenance information is collected and stored by humans in database systems that haven’t followed rigour in how information is captured.

So you end up with maintenance information that looks like this:

If you combine all the damage (failure info column) in one, you are assuming the damage mechanism originates and propagates the same across all. Is that correct?

If you find out that they all have different origination mechanisms. Then do you believe that what humans have labelled is correct? Could there have been a mis-entry? Or a misunderstanding even perhaps of what the failure is.

To solve these challenges faster, it’s important for us to continuously add to the Autonomous AI.

Growth update and the plan ahead

Distribution is important.

I have previously written about the importance of distribution in product development.

A lot of effort has gone into building multiple channels of distributing Amygda’s data observability platform for asset-intensive industries.

Soon, we will share more on this.

Here’s what we’ve been growing with

  • discovery calls with prospects
  • building partnerships with relevant partners
  • building a system for product development and roadmap
  • hiring (this is always ongoing)
  • fundraising

As you can see, there isn’t one thing that is the magic bullet. As a project, we are focussing on taking forward steps on many things.

Doing this with focus, persistently is what we are good at.

A beast at it actually. Very few people will outdo us on the persistence of breaking through things.

Of course, having a good network of folks to gain advice and insight from is important.

On fundraising – let’s talk

We are currently raising a seed round and in talks with good investors with who we align. And who has the network and past experience of helping startups who look like us?

However, I’ve also started thinking much more about angel investors (wiki: angel investors).

Not just from the prospect of investment. But angels who can provide operational support as well.

For example, having an investment of £5,000 to £10,000 from an angel is good. What’s even better is to have that investment from a sales leader, or someone from C-suite, who can bring operational or industrial experience as well.

Being an operator with us would be fun. In fact, I love operators. They are the true accelerators.

More on fundraising to come in the next few blogs.

To finish up

There is so much ongoing. And we need more hands-on deck.

To find out about roles we are hiring for, follow the Amygda page on Linkedin.


So what’s next?

The journey of building Amygda continues. We are a small team, here’s our Linkedin to follow us and keep a track of the jobs we are hiring for.