# Haris Mahmood > AI Research Engineer in Islamabad, Pakistan. https://harismahmood.dev Email: haris@harismahmood.dev · GitHub: https://github.com/hmahmood24 · LinkedIn: https://linkedin.com/in/hmahmood24 Resume: https://harismahmood.dev/resume.pdf · CV: https://harismahmood.dev/cv.pdf I build AI agents and the systems they run on. Most recently I was a founding AI engineer at Unify (YC W23), working on AI agents that companies onboarded like new employees. I built much of the platform under them, from the RAG pipeline that gave them a company's knowledge to the generative UI they acted through and their integrations with a company's own apps, and in 2026 led a ground-up redesign of Unify's open-source agent harness, with an agent mesh and a memory built for both memoization and generalisation. Before that I co-founded Ivy and led its source-to-source machine learning transpiler, which rewrote PyTorch models and libraries as working, readable TensorFlow and JAX, so a PyTorch model could run on Google's TPUs through JAX. ## Now I'm looking for my next role. Most of my work has been building agents and the systems around them: designing harnesses from the ground up, giving agents a company's own data to work with, and running them securely and reliably for real users. I'd happily keep doing that, and keep pushing how agents and their harnesses can improve on the job. The harness work at Unify also left me thinking that much of what an agent learns belongs in its weights, so I've been spending time on post-training: reinforcement learning against rewards that can be checked, the environments that training needs, and continual learning without forgetting. The [Research](https://harismahmood.dev/research) page says what draws me to it. ## Experience ### Unify, Founding AI Engineer Jan 2025 – Oct 2026 · Remote · https://harismahmood.dev/work/unify-2025 A startup that built an observability and evaluation platform for LLM applications, then AI agents that companies onboarded like new employees. - Built much of the platform the agents ran on: the RAG pipeline that gave them a company's knowledge, the generative UI they acted through, and their integrations with a company's own apps. - Led a ground-up redesign of the open-source agent harness, with an agent mesh and a memory built for both memoization and generalisation. On [Continual-ARC](https://github.com/unifyai/continual-arc), a benchmark Unify was building to test continual learning, the new harness solved more puzzles than the old one and than OpenClaw, Hermes Agent, and Prime Agent. - Built the tables and dashboards through which teams explored millions of logged traces and evaluations in its observability and evaluation platform. I rejoined [Unify](https://unify.ai), a Y Combinator company (W23), in January 2025 as a founding AI engineer, after the Ivy spin-out, and stayed until October 2026. I worked across the stack, from the Next.js web app and the backend to the agents' runtime and the harness around them. #### Unify Interfaces [Unify Interfaces](https://www.producthunt.com/products/unify-5/launches/unify-interfaces), launched in March 2025, was an observability and evaluation platform for LLM applications. Its SDK captured detailed traces of what an application did on each request, teams scored those traces with their own evaluations, and they explored the results in tables and dashboards they composed themselves. I built the tables and dashboards they explored it through, in Next.js. The hard part was scale. The tables let users drag, pin, and hide whole groups of nested columns and grouped rows on the server, so each group loaded only when opened, and on the backend the SQL generated from users' filters was shaped so PostgreSQL planned it well for small projects and for projects with millions of logged rows alike. #### Unify Teammates By late 2025 Unify had moved from watching LLM applications to giving companies agents that did the work. [Unify Teammates](https://www.producthunt.com/products/unify-5/launches/unify-teammates), launched in March 2026, were AI agents a company onboarded like a new hire, through calls, screenshares, and documents, and then worked with over Slack, Teams, email, and live calls. I built much of the platform under them, from the knowledge they drew on to the apps they wrote and the tools they used, and the shell of the web app that kept chat, live activity, and calls running from page to page. I also deployed pilots for prospective clients and supported their teams directly. #### Knowledge I built the RAG pipeline through which teammates searched a company's documents and computed over its spreadsheets. Rather than cutting files into fixed-size chunks of text, it parsed each document into a hierarchy that followed its own headings, from sections down to passages and sentences, with tables and images filed under their sections. An agent could land on a sentence, passage, table, or image and widen out to the passage, section, or document around it when it needed more context. Spreadsheets and document tables became typed tables the agent filtered, joined, and totalled in its own code instead of reading rows as text, and ingestion ran on workers that scaled with the queue and never marked a file done until every row was stored. #### Generative UI Teammates showed their work as small apps they wrote themselves. Asked for a view of overdue invoices, a teammate wrote a React app, called a canvas, on a component kit I authored, rendered it in a real browser to check its own work, and revised it from the screenshot. Canvases could also act, for example by emailing a report to a list of colleagues, and a model wrote that code, so I designed the boundary that made it safe on customer data. Each canvas ran in a sandboxed frame with no network access, where it could name an action but never see what it did, and the server checked every input, asked the user to confirm anything irreversible, and ran each action exactly once. #### Integrations and workflows I built the integrations through which teammates worked inside a company's own apps, connected through OAuth or API keys. They were designed around progressive disclosure: from inside the code it wrote, an agent searched for the app it needed, then for the tool, and loaded that tool's schema only when it was about to call it, so a company's many connected tools never crowded its context. Every call then passed through the permissions the user had set for that account, where each action was allowed, asked about first, or blocked, and an approval covered only the exact call it approved. On top of this I built installable agent workflows, which switched on once a customer connected the apps they needed. A recurring task that had worked could then be distilled into Python that called a model only for its judgement steps, so later runs were cheaper, faster and consistent. #### Redesigning the agent harness In 2026 Unify wanted its agents to get cheaper and more reliable the more they ran, and I led a ground-up redesign of the open-source [Unify agent harness](https://github.com/unifyai/unify-agent), in which an agent carries out each request by writing and running Python. The old harness was the first baseline, so I started by redesigning it from the ground up. The redesign left the agent with a single tool that ran code and made every other capability a Python object in a persistent sandbox, with help the agent read only when it needed it, so its context carried only what the task in hand required. It moved code the model wrote out of the agent's own process, where it could see access keys, into a sealed sandbox, kept the context lean with compaction as it grew, and ran follow-up work, such as reviewing a finished task, as a fork of the agent's conversation so it reused the prompt cache. #### Memory and the agent mesh I designed the new memory for two things: memoization, reusing work the agent had done before, and generalisation, transferring what it learned to new work. Each task was saved as one commit in a git repository, and after it the agent wrote up what it had done as a Python function. A separate writer merged related experience into a library of functions and notes, and a function earned trust only by working in later tasks, never by being re-run, since a function that pays an invoice should not run twice to check it. The agents behind it formed an agent mesh: the acting agent, the writer, a librarian that matched stored functions to new requests, and sub-agents in their own sandboxes, addressing each other directly on one global crash-safe, append-only message log. #### Results We measured the new harness, memory on, against Unify's old harness and against three published agents with their own memory: OpenClaw, Hermes Agent, and Prime Agent. On [Continual-ARC](https://github.com/unifyai/continual-arc), a benchmark Unify was building on [ARC-AGI](https://arcprize.org/arc-agi) to test continual learning, puzzles recur over a long stream of work and each has a budget spent on worked examples and wrong answers. The new harness solved more puzzles than the old one at every model reasoning effort, 73.5% against 62.5% at low effort, and used less of its budget. Against the published agents, with the same model and settings, it solved more puzzles at every effort and used less budget at medium and high effort; at low effort it used more than OpenClaw and Prime Agent, and it cost more per puzzle than Prime Agent. On an internal benchmark of office work I specified, a simulated finance team whose unwritten rules changed over time, it made 12 to 21 times fewer harmful mistakes, such as wrong payments, than Prime Agent. Across the designs, most of memory's benefit came from memoization rather than generalisation, which is part of why I now think much of what an agent learns belongs in its weights. ### Ivy, Co-founder and CEO 2024 – Jan 2025 · Remote · https://harismahmood.dev/work/ivy A Unify spin-out built around an open-source transpiler that rewrote machine learning code from one framework into another. - Led its source-to-source transpiler as technical lead. It rewrote PyTorch models and libraries as working, readable TensorFlow and JAX, so a team whose training platform was built on TensorFlow could adopt a model published in PyTorch as code its engineers could still edit. - Validated it on Hugging Face models and worked through Kornia until about 90% of its functions and classes transpiled, and Kornia's maintainers [merged the integration](https://github.com/kornia/kornia/pull/3045). In 2024 a few colleagues and I spun Ivy out of Unify, and I served as its CEO and technical lead until January 2025. #### The problem A model written for one machine learning framework could not use another's hardware or tools without being rewritten by hand. JAX and TensorFlow ran well on Google's TPUs, TensorFlow Lite put models on phones and edge devices, and most new models and libraries were published in PyTorch. Converters such as ONNX moved a model's computation graph between frameworks but not its source, so the result could run but was not code anyone could read or change. #### A transpiler that rewrote source I led Ivy's source-to-source transpiler, which rewrote PyTorch models and libraries as working, readable TensorFlow and JAX that mirrored the original's structure. At Unify we had traced models into computation graphs, which baked a model's control flow into whatever path its example inputs took. At the spin-out we rebuilt the transpiler on an architecture we had laid down late in 2023: it parsed PyTorch code into syntax trees and lowered it in stages, so loops and branches survived and the output was code an engineer could edit and train in the framework of their choice. #### Where frameworks disagree Most of the engineering went into the places where frameworks disagree. PyTorch updates tensors in place, while TensorFlow and JAX tensors cannot be changed, so in-place operations had to become reassignments without changing what the code did. I built that handling, and the cache that stored translations as serialisable syntax trees so shared code was translated only once, and fixed much of what real libraries exposed. #### Validation and adoption We validated the output on Hugging Face Transformers models by loading their pretrained weights into the converted models, comparing outputs with the originals, and training some of them in the target framework. The next target was Kornia, a computer-vision library for PyTorch, worked through until about 90% of a large set of its functions and classes transpiled. Kornia's maintainers [merged the integration](https://github.com/kornia/kornia/pull/3045), which I co-authored, in October 2024 and shipped it in Kornia 0.7.4. In November 2024 I relicensed Ivy under Apache 2.0, and the transpiler's source followed into the public [unifyai/ivy](https://github.com/unifyai/ivy) repository. #### Working with users As CEO I spent much of my time with prospective users. I ran technical demonstrations for enterprise machine learning teams, and the operations their models needed that we did not yet support set much of the roadmap. ### Noetico, Senior Data and AI Engineer Dec 2023 – Jun 2024 · Remote · https://harismahmood.dev/work/noetico Turning biomedical literature into a knowledge graph, and answering questions over it. - Extended a biomedical entity recogniser to new entity types by training it on its own misses, and linked what it found to the client's ontology of about 220,000 concepts. - Built an LLM agent that turned plain-English questions into queries over the knowledge graph. Biomedical findings are scattered across the literature, one relation at a time: this gene with that disease, this drug with that target. At Noetico I worked on turning them into a knowledge graph, which records how genes, diseases, drugs, and other entities relate to one another, and on answering questions over it in plain English. #### Extracting facts from text The pipeline used HunFlair to find biomedical entities in text, but it recognised only some of the entity types the client's graph needed. I extended it with training data built from its own mistakes: comparing its output with 10,000 annotated sentences and keeping only the sentences where it had missed an entity. On those sentences its existing taggers were fine-tuned and new ones trained for anatomy, drugs, gene groups, and phenotypes, then recombined into one model. I then linked each entity to the client's own ontology, through eight knowledge bases covering about 220,000 concepts, one per entity type. The linking doubled as a filter: a fact was kept only if both of its entities linked, which removed many of the recogniser's false positives and gave every fact the same identifiers as the graph. Relations between pairs of entities were classified with a pretrained biomedical relation model, used as supplied. #### Answering questions over the graph I also built a knowledge-graph agent for the question-answering service, in which an LLM, given the graph's schema and worked examples, turned a plain-English question into a TypeQL query, ran it against TypeDB, and wrote the answer from the result. ### Unify, Machine Learning Research Engineer II Mar 2023 – Apr 2024 · Remote · https://harismahmood.dev/work/unify-2023 Unify was then building Ivy, an open-source framework for transpiling machine learning code between frameworks. - Led the team building Ivy's graph tracer and transpiler, which recorded a model as a computation graph and rebuilt it in PyTorch, TensorFlow, JAX, or NumPy. - Extended the Ivy framework itself, its frontends, backends, and stateful API, so that converted PyTorch modules became trainable Keras models. I joined [Unify](https://unify.ai), a Y Combinator company (W23), in March 2023 as a machine learning research engineer, after contributing to Ivy as an outside open-source contributor. #### The problem In 2023 a model or library written for one machine learning framework could not be used from another without being rewritten by hand. Research code was mostly PyTorch, production stacks were often TensorFlow, and JAX was where teams went for TPUs and compiler speed. Unify was building Ivy to close that gap. #### The framework Ivy defined each operation once and implemented it for NumPy, PyTorch, TensorFlow, and JAX, then reimplemented each framework's own API on top, so code written for any of them could be expressed in Ivy and then in any other. I extended its PyTorch, TensorFlow, and JAX frontends, the backends beneath them, and its stateful API, where I made converted stateful modules behave as native ones, including PyTorch modules turned into trainable Keras models with tied weights and LSTMs. #### Tracing and transpiling I led the team building Ivy's graph tracer and transpiler, which ran a model on example inputs, recorded every operation as a computation graph, and rebuilt that graph in another framework. The hard part was what a trace does not see. A plain Python value such as `x.shape[0]` was frozen into a constant, so the graph broke on the next input shape. I made traces carry Python values as well as tensors, through proxy objects that behave like integers, shapes, and lists while recording what is done to them, and adapted a fork of TensorFlow's AutoGraph so built-ins such as `len` appeared in the trace too. The tracer also gained `jax.jit` support for transpiled Hugging Face models, and transpile time on very large graphs, such as FasterRCNN converted to JAX, fell from about 65 minutes to about 25. #### What tracing could not do A trace resolves branches and loops for the inputs it saw, so a converted model could not take a different path for a different input. Late in 2023 I restructured an early prototype of a different approach, rewriting the Python source instead of tracing it, into the staged architecture that the source-to-source transpiler at Ivy was later rebuilt on. #### Beyond the code Enterprise teams evaluated the transpiler during this period, and I prepared the builds and demonstration notebooks they worked from and supported them as they tried it on their own models. I also interviewed candidates for Unify's hiring team, and co-mentored a [Google Summer of Code](https://summerofcode.withgoogle.com/archive/2023/projects/kvfFWRyF) project to make TensorLy, a library for tensor decompositions, usable with every framework Ivy supported. ### CureMD, Machine Learning Engineer 2020 – Mar 2023 · Lahore, Pakistan · https://harismahmood.dev/work/curemd A healthcare software company. - Built SmartRecruit with one other engineer, before large language models: it parsed resumes of any layout and scored each candidate against the job in 2–3 seconds, and CureMD went on to use it for its own hiring. - Designed how it read each page, with our own algorithms for headings, columns, and reading order and custom-trained detection and entity-recognition models, at over 90% accuracy. From 2020 to 2023 I worked at [CureMD](https://www.curemd.com) as a machine learning engineer on document understanding: getting reliable information out of documents that followed no fixed format, before large language models made that easier. #### SmartRecruit [SmartRecruit](https://smartrecruit.ai), which I built with one other engineer, took the manual reading out of hiring: it parsed a resume of any layout and scored the candidate against the job in 2–3 seconds, against about three minutes for a recruiter. Resumes came in one column or several, heavy on graphics, and of any length. Candidates were scored with a model a recruiter could follow: weights for degree, institution, and grade, roles normalised to the O*NET occupational taxonomy, about 13,000 known skill terms, and separate weights for required and preferred skills. #### Reading a scrambled page The hard part was not finding a date or an employer but knowing which date belonged to which employer once the layout had scrambled the order of the text. We solved it visually. After named-entity recognition had found the institutions, companies, roles, degrees, and dates, each entity was drawn back onto the page as a box coloured by its type, and a custom YOLOv5 model we trained grouped the boxes into education and work entries. Headings were chosen by a vote among twelve candidate segmentations, and columns were found by sweeping a vertical line until it crossed no text, so a two-column page was read one column at a time. Parsing held better than 90% accuracy across layouts. #### In production Resumes arrived on their own, routed from CureMD's HR mailboxes through Microsoft Graph, and recruiters searched, shortlisted, emailed, and hired candidates in bulk from a web interface we built. CureMD used the system for its own hiring. Parsing, scoring, and document conversion each ran in its own Docker container on AWS ECS and Fargate, connected through RabbitMQ queues that persisted requests so bulk uploads were never dropped, with MongoDB for parse results, PostgreSQL for records, and S3 for files. ### N-ovative Health Technologies, Embedded Developer Jul 2020 – Sep 2020 · Islamabad, Pakistan · https://harismahmood.dev/work/nht A medical-device company, now Revive Medical Technologies, during the COVID-19 equipment shortage. - Designed the electronics and control system of a powered air-purifying respirator and worked on the software of the N-Saviour ventilator. In the summer of 2020, as COVID-19 spread, hospitals in Pakistan were short of the equipment needed to protect staff and keep patients breathing. N-ovative Health Technologies, a medical-device manufacturer in Islamabad that researches and mass-produces life-saving devices and implants such as coronary stents, set out to build respirators and ventilators locally. The company is now [Revive Medical Technologies](https://www.linkedin.com/company/revivemedicaltechnologies). I joined it as an embedded developer for that summer. I designed the electronic circuit and control system of the [NUST Powered Air Purifying Respirator](https://www.linkedin.com/posts/n-ovative-health-technologies-pvt-ltd_powered-air-purifying-respirator-is-ready-activity-6704409615955718144-ke8E), a device that supplies filtered air to the person wearing it, and helped with its quality testing and technical documentation. I also worked in the team building the [N-Saviour ventilator](https://www.linkedin.com/posts/n-ovative-health-technologies-pvt-ltd_a-team-of-biomedical-engineers-at-n-ovative-activity-6761895705155108864-wHfv), on its software algorithms and the interfacing between the software and the hardware. ## Open source ### Unify agent harness https://github.com/unifyai/unify-agent The [Unify agent harness](https://github.com/unifyai/unify-agent) is the open-source version of the runtime behind Unify Teammates. An agent carries out each request by writing and running Python, and can keep what worked for later requests. In 2026 I led its ground-up redesign, with an agent mesh and a memory built for both memoization and generalisation. The [Unify page](https://harismahmood.dev/work/unify-2025#redesigning-the-agent-harness) tells that story and gives the results. Before the harness was split out, I worked in Unify's full runtime, [unifyai/unify](https://github.com/unifyai/unify), on how teammates read a company's files, the apps they generated, and their workflows. ### Ivy https://github.com/unifyai/ivy [Ivy](https://github.com/unifyai/ivy) was an open-source, source-to-source ML transpiler. Given a function, a model, or a whole library written in PyTorch, it produced working, readable TensorFlow or JAX source with the original control flow intact, so PyTorch code could be compiled with JAX or deployed through TensorFlow's tooling as source an engineer could still edit. Graph converters such as ONNX move only a model's computation graph. I led it in two stages. At Unify I led the team on its graph tracer and transpiler, which traced a model into its computation graph and rebuilt that graph in another framework, and restructured an early prototype of source-to-source translation. At the Ivy spin-out the transpiler was rebuilt on that architecture, validated on Hugging Face models against the originals, and [merged into Kornia](https://github.com/kornia/kornia/pull/3045). It is published on [PyPI](https://pypi.org/project/ivy/). ### Kornia https://github.com/kornia/kornia/pull/3045 [Kornia](https://github.com/kornia/kornia) is a differentiable computer-vision library for PyTorch. With Ivy's source-to-source transpiler we worked through its functions and classes, fixing what the integration tests exposed in the transpiler until about 90% of them converted to TensorFlow, JAX, and NumPy. The integration, which added `kornia.to_tensorflow()`, `kornia.to_jax()`, and `kornia.to_numpy()`, was [merged by Kornia's maintainers](https://github.com/kornia/kornia/pull/3045) in October 2024 and shipped in Kornia 0.7.4. ### TensorLy https://summerofcode.withgoogle.com/archive/2023/projects/kvfFWRyF In 2023 I co-mentored the [Google Summer of Code 2023 project](https://summerofcode.withgoogle.com/archive/2023/projects/kvfFWRyF) that set out to build Ivy into [TensorLy](https://tensorly.org), a Python library for tensor decomposition, tensor regression, and tensor algebra, so that TensorLy would be usable with any framework Ivy supported. TensorLy's users would switch backends through Ivy's backend handler instead of TensorLy's own. Part of the work landed in Ivy itself, as TensorLy-style tensor decompositions. ## Research interests I don't have publications. I have six years of experience building machine learning systems, most recently nearly two years at Unify building AI agents, ending with work on agents that improve from their own experience. This page is about the questions that work left me with, and the areas I want to work in next. #### Post-training open models Much of what makes a model useful for real work is added after pre-training. I'm most interested in reinforcement learning with rewards that can be checked, such as whether an answer is correct or a test passes, because the signal comes from the task rather than from a learned judge. That makes it easier to reason about, though not impossible to game. I want to understand when it teaches a model something new and when it only sharpens what the base model could already do, and what makes an environment worth training in: tasks that can be verified, whose difficulty can rise as the model improves, and that look like the work the model will actually do. #### Continual learning A model that keeps training on new work tends to lose some of what it already knew. I want to understand how much of that forgetting is avoidable, through replay, staying close to the original model, or training on the model's own outputs, and how to measure it honestly, so that a gain on new work is not paid for with a quiet loss elsewhere. Distillation is where I think much of this gets practical. Fine-tuning a model on a stronger teacher's answers is the usual way to pass on a skill, but the student only ever sees the teacher's paths, not its own mistakes. Training on the model's own attempts, with a teacher or the model itself judging them token by token, as on-policy self-distillation does, seems to teach new behaviour while disturbing less of the old. I'd like to find out when that holds, and how it combines with reinforcement learning on the same tasks. #### Learning from a company's own data I expect companies that run agents to want them to keep improving from their own data and processes, and to do it privately, by post-training open models rather than sending that data to someone else's API. That makes the data flywheel the practical problem: deciding which of an agent's experiences are worth training on, checking them, and training on them without leaking anything or losing what the model already does well. #### Agent harnesses The harness around a model still matters. At Unify I led the redesign of an agent harness and its memory, which was built both to reuse work the agent had done before and to transfer what it learned to new work. Most of what memory gave turned out to be reuse rather than transfer. What I took from it is that much of what an agent learns on the job belongs in its weights, and that a harness is most useful when it gathers clean, verified experience to train on. How a harness and a training loop should divide that work is a question I want to keep working on. I'm working through these from the basics: reading, reimplementing the core methods myself, and running small experiments of my own. ## About I'm an AI research engineer based in Islamabad, Pakistan. I studied electrical engineering at the [National University of Sciences and Technology](https://nust.edu.pk), graduating with a CGPA of 3.69/4.00, and moved toward machine learning during the degree, through electives, online courses, and a final-year project on activity recognition. My first job, in the summer of 2020, was at N-ovative Health Technologies, now Revive Medical Technologies, during the COVID-19 shortage of medical equipment, where I designed the electronics of a powered air-purifying respirator. Since then I've worked on document understanding at [CureMD](https://www.curemd.com), on transpilers between machine learning frameworks at Unify and then at Ivy, the company a few of us spun out of it, and on AI agents back at [Unify](https://unify.ai) until October 2026. Each role has its own page, listed under [Work](https://harismahmood.dev/#experience), and the full record is in my [CV](https://harismahmood.dev/cv.pdf). Now I'm studying post-training of open models and running small experiments of my own; the [Research](https://harismahmood.dev/research) page says what I want to work on next. ## Technical skills - Languages: Python, TypeScript, SQL, Bash - Machine learning: PyTorch, TensorFlow, JAX, Keras, Hugging Face Transformers, PEFT (LoRA), vLLM, YOLOv5, spaCy, HunFlair, scispaCy - LLM agents: Code-executing agents, multi-agent systems, agent memory, RAG, tool calling, prompt caching, sandboxing (bubblewrap, seccomp), OpenAI and OpenRouter APIs - Program transformation: Python AST transformation, static analysis, graph tracing, TensorFlow AutoGraph - Documents and data: Docling, PyMuPDF, Polars, openpyxl, OpenCV - Backend: FastAPI, Flask, PostgreSQL (query planning, JSONB), SQLAlchemy, Pydantic, MongoDB, TypeDB, RabbitMQ - Frontend: Next.js (App Router), React, generative UI, TanStack Query, TanStack Table, Zustand - Cloud and infrastructure: Google Cloud (GKE, Pub/Sub, Cloud Run, Cloud Build), AWS (ECS, S3), Kubernetes, Docker, MLflow ## Education National University of Sciences and Technology (NUST), Bachelor's in Electrical Engineering, 2016 – 2020, CGPA 3.69/4.00 ## References - Daniel Lenton, Director and CEO, Unify AI Ltd, dan@unify.ai