Introduction
Agentic systems represent a shift from utilizing traditional workflows to managing enhanced LLM-based agents that coordinate, plan, and act, much like we do in real teams. This article tells how our levi niner, Alex, implemented an end‑to‑end onboarding AI workflow, showcasing where agentic autonomy adds value and how to properly make the most of it.
What an Agent Really Is
Although a language model stands at the core, an agent is more than just an LLM with a prompt. It is an autonomous unit that couples the model’s reasoning with various capabilities such as being able to perceive context, use system tools, call APIs, and all that is needed in order to pursue and achieve a concrete goal. When several such units collaborate, they form an agentic system, a coordinated team of AI workers that emulate the way we, as people, usually work together.
And it’s precisely because of that similarity that agentic systems architectures mirror human structures. They can be single‑agent (“one-man team”), network peers (decentralized, no leader), supervisor‑worker teams (a manager delegates work to subordinates), or hierarchical stacks (even managers have their managers). The more autonomy agents hold over the control flow, the more ‘agentic’ the solution becomes.
Why Multi‑Agent Designs Work
Just like putting a lot of work on one person, asking a single agent to handle everything will (almost) always go wrong. Basically, high chances are that you’re increasing complexity, adding security risks (too many capabilities in one hand), operability uncertainties (if anything fails, can the agent heal and recover on its own) and hallucinations (is the agent still reliable after a number of operations), while at the same time you’re decreasing explainability and maintainability. Splitting responsibilities across multiple agents introduces natural separation of concerns, improves testing and maintenance, and allows restricted tool access per agent for stronger security. The result is clearer ownership, better parallel execution, and a system that scales without losing control.
Capabilities Modern Agents Need
In order to build a strong foundation when designing our agentic system, there are five key pillars that we need to consider:
- 1. Reasoning & Planning: agents need to adapt and adjust based on the context (eg. consider an agentic system for an ecommerce customer-support solution: a person may call to inquire about a late order, a missing item, a refund or a cancellation; the agent needs to figure out what the next steps should be based on the person’s inquiry: ask for details? Query internal tools to crosscheck the inquiry? identify task and delegate work to a specialized agent? etc.)
- 2. Tool Integration: agents should be able to interact with external tools when deemed necessary (call APIs, query DBs, read or write files etc.)
- 3. Memory: agents might have to retain their state across multi-step tasks, but if that is not a constraint then you should try to keep your system as stateless as possible (minimize costs and hallucination risks altogether)
- 4. Dynamic Data Retrieval: agents must be able to pull in knowledge on-demand (eg. from well-defined internal sources, trusted external sources, etc.)
- 5. Behavioral Contracts: set up clear prompts to describe agentic behaviors and define strict output schemas (agents must know what they’re supposed to be doing, how they’re supposed to be doing it and how they’re expected to format their results before passing them further)
Agents in Action: Automating Employee Onboarding
Alex put this into practice by automating the most fragmented corporate process: Employee Onboarding. A new employee receives a link and a secret code; entering it triggers the system to generate a “levi niner profile”*, fill-in and sign internal acknowledgements, and present everything for approval. The flow touches on user interaction, agent-to-agent interaction, multiple data sources, API calls and validations, and ideal territory for multi‑agent orchestration.
* this is a webpage preconfigured with a levi niner’s information that the user can customize (think of it like a social profile).
Inside the System: The Supervisor Pattern
The architecture is grounded in a supervisor worker pattern.
Sam (supervisor) interprets the request, plans tasks, delegates work, gathers results, and incorporates user feedback.
Peter (profile agent) fetches CV and personal info via internal endpoints, then composes a customizable “levi niner profile”.
Daisy (document agent) retrieves, fills, and signs onboarding documents (various acknowledgements).
All worker agents run in parallel and never block each other.
Technical insight:
Agent communication & concurrency – the agents communicate via an Actor‑model approach, exchanging messages through dedicated “mailboxes”. This guarantees isolation, FIFO processing, and concurrency without shared memory, which fits the supervisor-worker pattern naturally. To get even more technical, the solution stack is based on Scala and Apache Pekko, with Gemini as the core LLM.
How the Workflow Runs
1) The user enters the onboarding code, which triggers the agentic workflow.
2) Sam decides which workers are needed and issues relevant instructions to each one.
3) Workers receive their instructions, call relevant internal APIs to fetch the necessary data and incorporate it into their task as needed.
4) Each agent reports back to Sam with results.
5) Sam presents the results to the user for review.
6) If the user asks for changes, Sam re‑delegates the instructions with an emphasis on the user’s feedback, so that the workers regenerate precisely what must change.
Tooling Layer & Data Access
In our use case, the worker agents need to query our DBs in order to retrieve the user’s relevant information. To achieve that, each agent has been designed to be aware of the tools they can use, in this case, a simple API with different endpoints for different types of data.
Peter calls a list of endpoints to retrieve the user’s CV and build up their profile around it.
Like Peter, Daisy can call a predefined set of endpoints for retrieving the new-joiner’s information, as well as the company’s onboarding documents templates to complete its task.
Sam has also access to various tools in order to clean up any previous work that wasn’t to the user’s liking.
An especially important thing to note is that, although pretty rudimentary for demonstration purposes, the API that exposes these said endpoints has been designed with agentic usage in mind, meaning that each call logs the invoking agent’s identity and in case of failures, the messages are explicit enough so that the agent can adapt and come up with a fallback or a retry strategy.
How Agents Know What to Do: Behavior Definitions
Agents aren’t mind-readers. To get them to do what we need, we must define their behaviors. And to achieve that, we can configure a special (or multiple, if necessary) file to describe what each agent is expected to do at each step in the workflow, the input they require, the tools they might use, reasoning boundaries, safety constraints (aka guardrails) and the output they should return.
Sam’s behavior on initialization, for instance, declares: “you are the supervising agent; these are your worker names and roles; here is the JSON response schema you must produce for delegation”.
These “contracts” guarantee us that each agent will behave according to our set expectations (or at least try to…).
Guardrails and Policy Enforcement
A small but telling example: a humorous piece of information in the CV was filtered out in the resulting “levi niner profile” webpage, not due to an error but because predefined policy rules forbid such content (remember how we set behavior definitions?). Guardrails apply right after the initial result of an agent to validate the work before it is persisted, ensuring alignment with organizational standards and reducing the risk of unwanted surprises.
Framework Approach: Rebuilding with Google ADK
After showcasing the inner works of a more “DIY”-like agentic system solution, Alex recreated similar behaviors with Google’s Agent Development Kit. ADK shortened scaffolding, simplified tool bindings, and visualized execution as a live graph. It also enabled voice interaction and provided traceable event timelines for debugging. Additional demonstration agents for a stock analyst, a news watcher, and a parallel system‑information auditor, were configured rapidly, illustrating how a framework accelerates iteration without obscuring core concepts.
Design Lessons to Carry Forward
- Think Small: Long chains amplify failure, set up minimum bounded contexts
- Budget Tokens: Large contexts are expensive, aim for a least state awareness architecture
- Explicit Tools: Agents don't 'discover' - they are taught, design tools with agentic usage in mind and define proper feedback
- Escalation Paths: Always provide a 'Talk to Human' exit, implement manual reviews in critical sections
