Paxio V1 Technical Blog

This is a comprehensive technical blog about Paxio V1, the engineering problems encountered, how we tackled them and how the systems work.

We will talk about the following:

1. Personal Assistant Working (Lucy) & Streaming
2. Interacting with Paxio using Whatsapp
3. Financial Assistant (Rob) Working
4. Experimenting with Agentic Quick Commerce & Food Delivery
5. Legal Assistant (Specter) Working
6. Autonomous Autoreply Email & Daily Calendar Fetcher
7. Autonomous Workflows
8. Memory in Paxio & Collaborate Mode
9. Additional Context to Query via Photos & Files
10. New Chat Interface Problem & Storing User Conversations and Chats
11. Various Nodes & Connecting Nodes
12. Experiments with Doomscroller
13. Keyboard Shortcuts, Reusable Prompts, Gemini API Cycling

Introduction to Basic Tech Stack:

• Frontend: Nextjs (React)
• Backend: Nextjs Serverless
• DB: Prisma ORM + Postgres DB (NeonDB)
• Streaming Service: Socket Server (socket.io)
• LLM: Gemini (2.5/3) for Brain of Paxio system
• CICD: Github Actions
• Cloud: Deployed on Google Cloud VM (Virtual Machine)
• Agent Framework: Langchain (Typescript SDK)

1. Personal Assistant Working (Lucy) & Streaming:

Now a major feature of Paxio is the Personal Assistant (Lucy) which allows users to manage their Gmail, Google Calendar, Google Docs, Google Sheets, Notion, Google Drive, Outlook, Calendly, Google Forms, Typeform, etc.

Along with this we also had some other ideas but couldn’t execute them:

1. Zerodha: Has paid API Plan for multiple user support, so could have done BYOAK — Bring Your Own Api Key
2. Fireflies: Paid Software to even get started with it or credit card for free trial also
3. Hubspot: Custom CLI required to manage it
4. Slack: Does not support localhost for testing (could have used ngrok)
5. Linkedin: Needed verification first of the business, no free trial support for testing
6. Discord: Needs https instead of http (thus no localhost testing support)
7. Twitter: Faced some problems with connection (error with Twitter OAuth using PKCE where it generates a secure code verifier, stores it temporarily in a cookie and then sends a hashed code challenge so that later callback can verify login securely)

Now Let’s start with the Working of the system:

A user inputs query from the frontend with Personal Assistant (Lucy), it comes to Paxio Chat Engine then routed via Assistant Router to Personal Assistant along with socketId to sustain the socket connection allowing streaming of intermediate responses powered by the socket service.

Then it checks whether the query is General Purpose or not, which can be answered simply by the LLM with the added memory (which we will talk about below) or requires a workflow to be made and executed.

To find out whether it is a general/workflow query, an LLM call with suitable prompt is made with few shot prompting (based on context of the functions available to be carried out by workflow) based on asked query.

A. General Query:

• If it is a general query, suitable response and suggested queries (which the user can ask next related to it) are shown

B. Workflow Query:

• If it detects a workflow, it takes this through the Planner

Planner:

The Planner firstly checks the nodes which are permitted by the user (like google calendar, gmail, etc) after which a call to LLM is made which contains a prompt (including all the Nodes + their Tools + Arguments required by each tool to run)

Ex: Gmail Node contains readEmail(), sendEmail(), deleteEmail(), draftEmail(), deleteEmail() as seen above.

Now this prompt is used to take the query by the user and convert into a step by step plan to execute the workflow by planning out which node has to be called in what order plus what tool to call in each node with the arguments to be passed and instructions/task to run in the nodes also.

This is all done by the Planner.

Consider these examples which are present in the prompt showing how the Planner functions (with few shot promoting)

This returns a JSON payload extracted in the following manner of each node (like google-docs, gmail, google-calendar, google-sheets, outlook, google-forms, etc).

We also have 2 special nodes:

1. start-of-workflow: Indicates start of workflow
2. end-of-workflow: Indicates end of the workflow. It also includes fields like:

• qnsToAsk: which are additional follow up questions which must be asked from the user to carry out the workflow (to fill in the missing information)
• permissionsNeeded: which includes a list of nodes which are needed for the execution of the workflow (that is indirectly user’s query) but user has not given permission for these nodes yet.

Also when Planning starts (by Planner) a loading state corresponding to Planning is streamed to frontend via the streamMessage() function with the socket service, and once it is done successfully it shows a correct tick else if failure occurs it shows a cross as shown below.

Now the socket utility works in following way:

The socket is used to establish 2 way connection with the frontend and also exposes API routes which can be called by the backend to receive the data (from the frontend).

The main working of the socket is explained below in the diagram with the custom events & built in events used along with their functioning

After a lot of example queries tested and seeing the planner hallucinate and fail, we added the following additional rules and important points based on our learnings while testing the system to guide it, since planner is the most important aspect of the entire system.

To ensure it works reliably, we also added some more examples for use cases & categories that the planner would fail at, after understanding the underlying theme/root cause of LLM failure (investigating the question: “Why did it hallucinate ?”)

Cross Verifier:

Now after the workflow for a query is created from Planner component, it is passed to Cross Verifier.

Also the nodes to be permitted are streamed to the frontend with a UI to allow user to connect them, only after which the next part would take place.

Then it streams the questions to be asked to the user on frontend in a form based UI, which user can answer and submit after which these question-answer-for triplets are added to the context of the workflow payload made by the planner.

After this is done, it returns the enriched workflow with added context of follow up questions answered by the user (if any) plus nodes which were required for workflow but not connected (if any) as connected.

The answers to the questions are also checked to ensure all required information is obtained using following prompt.

Workflow Runner/Orchestrator:

Now it is passed to the Workflow Runner which starts running the workflow from the start-of-workflow (marking start).

It finds the required nodes to run in the node registry and runs them one by one passing

• task — what to do in that node (generated by planner)
• relevant answered follow up questions for the node (done by cross verifier) as input to the node
• plus the AGENT logs which shows the results of previous nodes

Let’s take an example of a Node like “GmailNode”

How nodes work and connecting of nodes is covered later (this diagram gives a basic understanding of it). But the major steps are:

• It gets the task, params
• Establishes connection with Gmail APIs by fetching the Access token from DB or if expired use refresh token to get a new access token
• Now GmailNode like every node has a lot of tools defined for different purposes like readEmail, sendEmail, etc
• It executes the task defined at that node (by calling relevant tools), extracts in markdown format the output (to stream to frontend) plus added to the Agent Logs (which keeps track of the results of the nodes executed so far so that the next node knows what is already done)

Designer:

Now after Workflow runner finishes executing the workflow, it heads to the designer which takes context of the outputs of the nodes which have run (from the Agent Logs) to craft a final summary to show to the user.

A fully completed query example is shown below

It returns a payload with an output summary of what has happened in the workflow plus three suggestions (as queries which the user can ask by simply clicking it).

We were also working to enable parallel execution of non related tasks also (VS sequential execution of all steps right now) like the following forming a graph structure.

2. Interacting with Paxio using Whatsapp:

• We wanted to expand the use of Paxio to other channels like whatsapp (in addition to the webapp) so we used Meta Manager and its Developer Dashboard to setup APIs with a phone number which was provided by Meta free for 3 months time period (which was great for testing) to new developers

• Now a big challenge was that Meta provided us with an access token to use wapp, and no concept of refresh token in the free plan
• So for testing we had to create new credentials to interact with paxio plus ngrok bridge since it did not support localhost

• The System was simple, when any new user chatted with the given Paxio Agent (prev Bart) it would detect their phone number in the DB (if existing user) otherwise tell them to connect the Wapp Node inside the Paxio dashboard with a link to be able to do so

• And once Paxio had identified the phone number to the user, it would send the request made by the user to the Paxio Engine to execute the query
• A big challenge was the fact that we had to send streamed messages back to the user informing them about completion of various steps or information updates of executed nodes (like if a gmail message was sent, sending info about the message sent and to whom, etc to the user)
• Now this was tricky to do, since it is hard to track which messages had already been sent so we created a common utility called sendWhatsappMessage to send and track messages each time

• We encountered some errors like duplicate sending of messages, mismatch in the order of messages being sent due to race conditions
• Then we wondered why not be able to send voice notes/audio clips as a query instead of just plain text (as we all know speaking is faster than typing)
• So we added a simple pipeline to get an Audio clip from whatsapp, then perform STT (Speech to Text) powered by Deepgram API, then pass the extracted query through the Paxio Engine, return the streamed messages and finally send the response summary with follow up queries related to the current one which user can ask

• We also experimented a little with adding photos, files as additional context but encountered a problem. If any arbitrary photo is being sent unless it is part of a ongoing query it is hard to tell which query it belong to: New query or Additional context to past one ?
• Plus our mechanism had the concept of asking follow up questions to the users if they had missed some info (For example, user asked Paxio to send a happy birthday message to Anish, but did not mention the email address or style of the messages, then it would ask for it)
• If a user sends an answer to a follow up question, it is hard to identify if it is a new query written by the user or answer to the previous one, so we added a mechanism to maintain the state of each user to solve this

3. Financial Assistant (Rob) Working:

Now to explain how the financial agent (named Rob) works and what it does.

User can enter their budgets for the month plus their spends in a clean UI modal for each month forming a simple expense tracker embedded within the chat interface.

Now the power is that the users can ask questions to Rob via use of “@budget” (which automatically injects the Budgeting & Expenses of the user into the query before sending the request to the backend) thus the Assistant can provide more specialised assistance.

User can also reference their expenses and ask Rob (the Financial Assistant) to analyse it plus follow up questions.

This provides value since user does not have to keep on providing context to LLMs (like ChatGPT, Gemini, etc) about their current financial states.

Firstly we toggle to Financial Assistant, write the query which heads to Paxio Chat Engine routed to Financial Assistant, wherein there are 2 subroutes to go to:

a. General Finance:

• Wherein general queries are answered by RAG (Retrieval Augmented Generation) on a curated set of 20 + financial documents and PDFs with ingestion process where they are chunked and converted into vector embedding (via gemini models) which are then stored in ChromaDB locally

• Now for the inference process, it takes the query through a Naive RAG pipeline (with semantic search only instead of SOTA hybrid search for simplicity) and fetches the relevant chunks which are then added as context to the Financial Agent for general purpose tasks

• Then it returns the answer along with some suggested additional queries user can ask ahead

b. Finance Router: There are 2 ways to go to:

• Add Expense: Wherein a new expense is added to be stored in DB by first extracting given expense in a structured json format (tags, expense details, amount, currency, payment methods, recurring, location, note, receipt url if any, sentiment, spend type, category, sub category) as shown below

• Analyse Expense: Wherein user can ask a query with respect to their expenses (already present in the DB). It firstly identifies which aspects to analyse and then generates suitable graphs (which are interactive) to visually explain the analysis performed.

Some examples of Financial Conversations are below:

4. Experimenting with Agentic Quick Commerce & Food Delivery:

• Ref: https://github.com/anishs1207/autonomous-shopping

• We were solving the problem of agentic commerce wherein you tell the Paxio Shopping Agent to order something, let’s say a packet of Blue Lays chips and it will find it for you, ordering it from Zepto
• Now the pipeline we got working is firstly to select the “Shopping Agent” inside the Chat Interface (/chat or /c/convoId), enter the query “Order a Packet of Blue Lays Chips” and click submit
• The request is passed to the PaxioChatEngine and routed to the Shopping Agent with inputs:

1. prompt: query written by the user
2. socketId: socket Id of client connected to the socket server
3. userId: internal userId of the user in DB
4. files: additional files or image based context provided with the query, like say a shopping list

• Then it continues the flow & streams updates to the frontend (via “streamMessage” utility) with the query being transformed into a structured JSON payload (check below) by an LLM call with following prompt

• streamQuestion is used to ask follow up questions to fill in the gaps of information given by the user and once the final payload is made for the products, it calls the Python FastAPI Service which spins up a headless browser (powered by browser use’s python library) which actually starts the core ordering part of the blinkit/zepto flow process

Steps followed by Zepto Flow:

a. Visit Website:

• It goes to zepto.com website, sets the location of the user & their phone number (obtained when the user connects the Quick Commerce Node in Paxio dashboard)

b. OTP Generation:

• Then it clicks submit to send OTP (One Time Password). During this process it also takes screenshots of the process taking place to be streamed on the frontend
• We faced challenges in doing this reliably due to conversion from base64 to image format with other issues of latency as well, after which we eventually moved to cloud hosted version of BrowserUse in Paxio V2

c. OTP Verified:

• Now we get the OTP on the user’s phone number, which they enter in UI which reaches the python service with the socket connection
• Now in this case many edge cases existed like what would happen, if the user did not enter the correct OTP or not even enter one at all, so we added a timer of about 2 minutes after which the request would be termed as failed and
• the browser instance would be closed

d. Ordering of Products:

• Now once OTP is confirmed, the product list of items is searched one by one and then added to the cart.

e. Product Confirmation & Checkout Process:

• Once all items are added it sends a picture of the cart to the user (in the frontend) seeking confirmation following the checkout process (involving confirming the address & entering UPI Id for payment which were again obtained on the connection of the Quick Commerce Node)

• Finally user can confirm the transaction made on their UPI App following closage of the browser instance and response returned back to user in the frontend

We tried similar experiments with Blinkit and Swiggy. This process involved understanding the core flow from visiting the website to the checkout

We did a lot of Trial & Error (and encountered new edge cases) which we then used to update the prompts of the navigation to make it work reliably.

Before heading on to Browser Use, we tried native playwright (which required very low level injection of JS Scripts to run the tasks).

Shifting to Browser Use was better and faster (especially on the cloud plan we used later). Another problem we were working on was being able to cache user credentials & session in our DB so that user does not have to give the OTP each time to connect their accounts.

Some other challenges that we encountered was that sometimes a required product was not in stock (in the userby dark store location of the user) or sometimes multiple versions of the same product are available (so we added another field to indicate from user prompt if they want the cheapest, most relevant, etc options).

5. Legal Assistant (Specter) Working:

Now to understand how the Legal Assistant works, when a user enters a query it is passed to Paxio Chat Engine and routed to Legal Assistant.

After that it does RAG on a curated set of Legal Data and PDFs which have been converted into vector embeddings (stored in ChromaDB) using similar RAG Pipeline to one done with Financial data.

The Legal data comprises of PDFs of:

• Constitutional Law (Directive Principles, Fundamental Rights, Indian Constitution)
• Landmark Judgements by SCOI (Supreme Court of India)
• Law School Notes
• Legal Commentary Books
• Major Acts, etc

Finally this gives the response in markdown format (to be rendered in the UI) along with additional queries related which user can ask by simply clicking it.

6. Autonomous Autoreply Email & Daily Calendar Fetcher:

Autoreply Email feature automatically reads all emails sent to a user and autoreplies all of them based on the context of the user and their reply style

It also gives the users an option to send custom follow up messages to the AI message also, plus we also brainstormed to add blacklisting and whitelisting of emails (whom to auto reply or not to)

The context of replying is based on the memory collected with user’s past interactions and information about user

It starts up a worker which periodically polls the DB for active autonomous tasks, registers new ones for execution and also unregisters tasks that are not longer active or deleted, running all relevant tasks.

And Daily Calendar fetcher feature fetches your daily items present in your google calendar providing a unified interface for a user.

Now for the working of these, they are special prebundled examples of autonomous workflows which are explained below

7. Autonomous Workflows:

Personal Assistant comes pre-bundled with Gmail Auto reply and Daily Calendar Summary along with ability to make custom autonomous workflows for custom needs, which the user can create.

The underlying engine works in similar way to the normal Personal Assistant (with the Planner, Cross Verifier, Workflow Runner, Designer, etc) with Cron jobs.

Now to create a new workflow, there are 2 ways to do it:

1. Prompt only (which specifies when to take place, trigger and what to do)
2. Prompt + Schedule (when to occur) + trigger (on what event to execute) given separately

Each time an autonomous workflow takes place, it is logged with the time of invocation along with output logs associated with it (via use of the designer) and stored in the DB to view the results of its various runs.

Users can also edit a previously created autonomous workflow also to modify it thus giving extendability into existing workflows.

8. Memory in Paxio & Collaborate Mode:

There are some steps followed in preparation of memory.

Initially query is passed to Paxio Chat Engine from frontend which is then enriched with a list of tags, context of prompt, and memory (explained below)

a. List of Tags:

• list of tags present in the user’s db (related to various broad topics)

b. Context of Prompt:

• Takes the query & tags obtained from above and uses an LLM to extract the context and meaning of the prompt so that it can later be used in memory stage
• It obtains a JSON payload with context, tags (global descriptions to be able to see what category the query lies in), trigger (used for what similar memories should be fetched by it) for the query

c. Prompt Embeddings:

• Then it goes through the prompt embeddings sections wherein embeddings are generated (dense embeddings for the query + averge embeddings for the trigger and tags remain as there are)
• The obtained payload with context, trigger and tags is taken and embedding for context is obtained using Xenova/all-MiniLM-L6-v2 from “@xenova/transformers” client sdk in TS (Typescript) which loads the model in memory

Now it goes to the memory layer built by first principles thinking.

d. Memory Layer:

It uses a combination of 4 types of memories:

a. Immediate Conversations:

• Simply fetches the last k user-assistant pairs from current conversation (we found k=4 to be useful) and formatted in the following format
• It is used to enable continuity in conversations with the user (so that the agent knows the context for what is being taked about)

b. Working Memory:

• It includes all those short term memories which belong to same conversation (that is they have same conversationId as current conversation)
• It provided the model with context of the overall flow of conversation with most relevant chunks for the query asked by the user
• It uses the following formula & weights to score the different fetched memories in comparison to the entered query

• We did not test these weights extensively to check the ratio between the various scores (contextScore, triggerScore, tagScore, distanceScore, lastUsedScore)
• Then we took the top 5 scored memories which are then added to the working memory given as context to the agent

c. Short Term Memory:

• It fetches the current memories and scores them based on the below formula and chooses the top k % of short term memories (we took k = 20 %)
• It provided relevant facts and past conversations with user and assistant across different conversations also

• Now for addition of Short Term Memories (STMs), once each query is executed by Paxio Agent an STM is added by extracting all relevant information of Response-Result pair and added into DB as a new unit

• Also we added a mechanism to combine Short term memories if they reach a certain weighted similarity

d. Long Term Memory:

• Similar to short term with the following formulas for long term contextual information

• But the change is how Long term Memories are created. We planned to create a mechanism where the STMs become LTMs when they reach a certain level of usage & relevancy
• To Promote Memories to become LTMs (Long Term Memories) and also demote them when they do not meet a certain criteria or say a TTL (Time to Live) objective

These are some notes from the earliest ideation of this part of the memory system

Collaborate Mode:

We added a feature by which if a certain assistant is being asked something say Lucy (Personal Assistant) but it feels that for better functioning it needs the expertise of some other specialised agent, say a Specter (Legal Assistant), then it can call other agents to collaborate on tasks.

9. Additional Context to Query via Photos & Files:

• To solve this problem to provide additional context just like ChatGPT, Gemini, Claude etc, in addition to text queries, we uploaded these to the local file repository inside /public with /files (to store files) and /images (for images) for ease (to avoid setup with cloudinary or AWS S3 at that stage) when request is made

• We used a system wherein when the submit button was clicked the context (files/images) was first stored locally via special route and then its context was added in addition to user query sent to the Paxio Engine
• For Images we used Gemini Models and for files, we generated Vector Embeddings with RAG to retrieve relevant chunks (based on user query)
• To avoid collision of same file names, we create a new uuid for the image as shown below

• We also experimented with uploading the images and files at the instant when the user uploads them VS when they hit the submit button to improve the user experience and feel seamless

We added Voice Inputs also (to speak the query) wherein we used Deepgram API for SST (Speech to Text) along with silence detection (for better UX)

10. New Chat Interface Problem & Storing User Conversations and Chats:

• The problem is that whenever a user lands on the main interface (/chat) they have no conversations opened yet, so they see a UI with just a chat Input box in the center (checkout below)

• But when they type a query (like “do xyz”) the system should automatically create a new conversation for it taking them to /c/conversationId such that query and additional context (images, files) would reach there also

• We solved this by simply taking the prompt (do xyz) and encoding it into the URI (Uniform Resource Identifier) of the /c/conversationId as ?p={encodedURI} redirecting to it and finally extracting it
• But for images, we employed a solution to firstly temporarily store it in the session storage, and then consume it when calling the backend system

Now the problem is a classic one, when we create a new conversations or store chats in an existing conversation, there are 2 methods to follow:

1. Optimistic UI update: It involves adding the chat in local Redux store with a local Id, and once DB confirmation is received to replace it with the DB generated uuid or revert if DB transaction fails
2. Wait for DB Confirmation: It involves waiting for DB confirmation and not showing addition in UI until confirmed, which offers bad UX for users

While both of them are valid and confirmation from DB usually happens quickly, there is a delay period. It’s often better for UX (User Experience) to follow the first approach, which is what we implemented.

Now the same thing happens when you ask a question to one of the Paxio Assistants (Optimistic UI update in local redux store, then replaces with the uuid of db after confirmation) plus when streamed messages are updated (planner was “streaming” but now in “done” state, then these changes are first done locally with tempId and then replaced after DB confirmation)

Now let’s also go over the Frontend streaming logic flow

The stuff which happens in the frontend when the submit button is clicked

It starts with the query written by the user, either in /chat (where query is encoded in the URI, new conversation is created in local redux store, files and images are stored in session storage and finally redirected to /c/convId)

Now either in an existing conversation or one just created (encoded prompt is extracted), form Data is generated with files & images (from session storage if just created), prompt, socketId.

Images & files (if any) are saved first via /api/save-media API route, then the user query is stored in the redux local store (replaced with actual DB Id after confirmation). Then main /api/response route is called (Paxio Backend) and once entire flow is done it returns the response.

11. Various Nodes & Connecting Nodes:

We divided the nodes into 3 main categories:

a. Outreach: Gmail, Outlook, etc

b. Scheduling: Google Calendar, Calendly, etc

c. Workspace: Google Docs, Notion, Google Sheets, etc

We figured out that adding new nodes for new integrations involved adding config stuff in a lot of scattered places, so we developed an SOP (Standard Operating Procedure) to do so easily and created a Registry of all Nodes which holds their logic.

Now each node works in the following way. It is called by the workflow orchestrator to run with the given instructions (along with Agent Log which shows results of the past executed Nodes in the workflow), it tests & loads the credentials (if expired, uses refresh token to renew access token)

Then the agent (built with Langchain) calls the required tools (integration APIs) to carry out the task, which is streamed to the frontend and finally its result is added to the Agent Logs and control moves to the next node to be executed.

Some Unique Nodes we added apart from the standard app integrations include Creative Node (for isolation of creative writing tasks to prevent Context Rot problem) and Search Node (which involves calling the Serp API key for web data)

Connecting Nodes:

Now to manage so many node connections with integrations like Gmail, Outlook, Google Drive, Google Sheets with the standard OAuth 2.0, we enable users to connect via simply clicking on connect button in UI.

Now to explain in detail, we also mention the required scopes which are needed for 3rd party integration (which appear in the OAuth form showing the user, what scopes they are giving permission to use)

It then redirects them to the Authentication Page, after which the callback returns the OAuth tokens (Access Tokens and Refresh Tokens) along with Expiry which is stored in the DB, so that user does not have to connect their nodes again and again.

And upon disconnection, the tokens are removed from DB. Special Nodes like Quick Delivery (which collects the phone number, location, UPI Id) and Accountant Email (to directly send financial budget each month), etc.

While testing we found out that for connection of Google related nodes in production, one has to do a SOC 2 compliance for security since unrestricted access to google related products by a third party site leads to many vulnerabilities.

12. Experiments with Doomscroller & AI Calls with Vapi:

We also explored an interesting problem of creating a Doomscroller to scroll the entire web given a query to monitor what is going on the internet (trends, news, sentiments, etc) which should have a big use case for companies.

Now once a query is executed we have a list of trusted sources (like reddit, wikipedia, etc) from which it gathers the information and is compiled into a report in markdown format to provide to the user.

A User could simply turn an agent ON to search for some XYZ topic across all relevant sources for say 20–30 mins in detail by browsing the internet similar to how a human would do it, run autonomously and come back with the final compiled report.

13. Keyboard Shortcuts, Reusable Prompts, Gemini API Cycling:

We added some keyboard shortcuts for common functionalities shown below

We added a collapsible sidebar (via use of ShadCN components to relieve us of the load of building beautiful native UI elements), with the user conversations showing just like in other LLM interfaces with user profile sections in addition to an intuitive and minimal dashboard.

Now we managed to allow users to try out the product plus while testing we were working with free Gemini API keys, so we added 6–7 keys and added a system, when if one would reach daily limit, it would automatically cycle to the next one without disrupting the flow.

Now we also provided the user the ability to reuse prompts written before as seen below.

Checkout the waitlist video here

[embed]

And demo video below to get an idea of the features & working

[embed]

Hope you enjoyed this and learned from our experiences