Behaviour-Driven Development (BDD) is a software development process. As the name implies, it is based on the idea that the expected behavior of a system is defined before the source code for that system is written.

The behavior is documented in the form of a suit of tests that can be executed to validate how the system responds to a set of examples that cover the use cases of that system.

What events should my component publish? Not always an easy question to answer.

Software design is a continuous task. You never finish a software project, because it needs to evolve as the team’s knowledge about the problem it solves grows. This is why one of the principal characteristics of good software is being easy to change.

In an asynchronous software architecture, the events that a component publishes define its contract with the other components in the system. And a good interface contract is one that lets the component be useful to the other components, while making it easy enough to modify as the project grows.

A few days ago I stumpled upon this LinkedIn post (in Spanish, but easily understandable) including this image with two solutions to the same problem:

A software system is considered Multitenant when it can serve multiple clients with different data. Each registered user is part of one tenant, and will have access to the data that their tenant owns only.

In this article I will be covering how the Micronaut framework supports the creation of multi-tenant applications, as well as many other useful features for general development.

Large Language Models (LLMs) use Neural Networks to identify and learn patterns from large amounts of text documents. Simply put, they read so much text, that whenever you give them the beginning of a sentence, they have a very high chance to predict how it continues.

This ability of predicting the next word for a given sentence has opened the door to interacting with machines using natural language, a whole new interface.

What does it take to build a system where multiple agents can interact asynchronously, respond to user queries and take proactive action when things change around them?

Many articles already explain how to build an agent with existing libraries and SDKs. Here, I’ll cover what else you need to create a multi-agent system: a future-proof architecture that supports asynchronous communication, works with any tooling or models, and runs locally on varied hardware.

Prerequisites This is a dense article that introduces many concepts without fully defining them. Some familiarity with LLMs, the concept of agentic AI, and how to build agents is advised, in particular with LangChain4J and Jlama.

The field of Artificial Intelligence began to develop after World War II (the name was coined in 1956). But it wasn’t until the late 20th century that widespread applications began to emerge, with the first spam detectors and recommendation engines.

In the 2020s, the emergence of Generative Artificial Intelligence appears poised to revolutionize the way people interact with technology.

My last side project was a proof-of-concept multi-agent platform called A.M.I.C.A.. Among other features, it provides centralized tool management, allowing agents to search for relevant tools when handling user requests.

The initial implementation of the Tool Manager interface was the LuceneToolManager class, which used an in-memory Lucene index to search for the tools relevant to a user prompt.

After publishing the article, I thought that it would make sense to create another implementation that used semantic search, as it is a more powerful mechanism to identify relations between text fragments.

API-First development (also known as Contract-driven development) starts by designing and documenting the contracts between the components that build your system (services, user interfaces, third party providers, etc.) before writing the source code.

There are many benefits to this approach. Some of the main ones include:

• Central Source of Truth: The API specification serves as the definitive guide for component behavior, simplifying testing and validation.
• Parallel Development: Provider and consumer components can be developed simultaneously.
• Automation: Shared artifacts of the system can be generated directly from the specification documents.

An API specification document describes two things: component behavior and shared data schema. For component behavior we use specifications like OpenAPI for REST APIs, or AsyncAPI for Event-driven Architectures. These specifications allow us to define how our components interact, which endpoints they expose, which messages they publish and consume.

@ThreaderBot listens for Twitter mentions. When someone sends it a link, the bot will:

• Download the content of that link
• Extract and clean the text
• Summarize the text into up to five sentences using the TextRank algorithm
• Answers the Twitter mention with a thread including the generated summary.

The bot is developed in PHP with Symfony, and runs as a cron job in a Raspberry PI.

TextRank algorithm was introduced by Rada Mihalcea and Paul Tarau in their paper “TextRank: Bringing Order into Texts” in 2004. It applies the same principle that Google’s PageRank used to discover relevant web pages.

The idea is to split a text into sentences, and then calculate a score for each sentence in terms of its similarity to the other sentences. TextRank treats sentences having common words as a link between them (like hyperlinks between web pages). Then, it applies a weight to that link based on how many words the sentences have in common. ts-textrank uses Sorensen-Dice Similarity for this.