DEV Community: Stephen Ingham

Building a Job Post Recorder Agent with Google ADK and Composio

Stephen Ingham — Fri, 07 Aug 2026 22:09:39 +0000

Photo by Glenn Carstens-Peters on Unsplash

Intro

If you're on the job search like myself (at time of writing), I'm sure you'll know how critical it is to spend your time efficiently.

You certainly don't want to spend additional time on admin, manually copy-pasting the details from the job description into whatever tool you use to track job applications.

That's why I've made a tool to automate this part of the process, a multi-agent system which auto extracts and pastes the relevant parts of job posts you care about directly into your Excel workbook sheet of choice!

In this article, I cover my learnings figuring out how to work with Google ADK and Composio while building out this system - covering the architecture, the issues encountered and final takeaways for anyone wanting to tackle their own projects using these technologies!

Hope you enjoy!

Google ADK/Composio Briefer

Before we jump into things, I thought it would be worth giving a brief overview of Google's Agent Development Kit and Composio

(I'm assuming in this overview a prior basic understanding of LLMs, agents, tools/MCP servers - if you're not already familiar with these terms they might be worth a google search first)

Google ADK

Google's Agent Development Kit (ADK) is a scaffolding framework for building production fit agent-based systems.

It offers a lot of flexibility around composing systems, especially v2.0 which introduced graph-based workflows which made it quite straightforward to implement conditional logic and more complex deterministic systems (compared to offerings of pre v2).

The Google ADK supports SDKs across a number of languages, but the best supported SDK (alongside Go) at current is Python, so although I'm usually more of a TypeScript user, this dictated my language choice in this project.

A handful of ADK-specific primitives come up repeatedly later in this article, so I'm defining them here sooner than later!:

output_schema - a Pydantic model you attach to an Agent to constrain its final response to a specific JSON shape (e.g. {header: value} pairs matching a spreadsheet's columns), rather than free-form text.
Callbacks (e.g. after_model_callback) - functions you hook into an agent's lifecycle to inspect or rewrite what it's about to do or just produced, without changing the agent's own instruction/prompt.
ctx.state - a shared key-value store (a "blackboard") passed through every node in a Workflow, letting one node write a value (e.g. the extracted job URL) and a later node read it back, including interpolating it directly into another agent's instruction string.

If any of these feel abstract right now, they'll click once you see them in context later in the article.

Composio

Composio is a managed platform which makes tooling integrations accessible to AI agents.

It offers toolkits for working with a large number of platforms, from GitHub to Bitwarden, and as well as being model agnostic it handles the auth to these platforms for you (which is a major reason why I chose to use it!).

Generally speaking, it operates by exposing the signatures for a set of 'meta tools' to your agent which based on the query the agent sends finds and returns the signatures for the tools Composio believes you need to perform the requested task (avoiding context bloat that would otherwise occur in loading in the 200+ tool signatures Composio could present to the agent!).

Now you've got that context in mind, lets discuss the project!

Why an Agent-Based Approach?

Photo by Immo Wegmann on Unsplash

Before I got started, I knew what I ultimately wanted should be quite straightforward.

I needed the system to reliably navigate to a job URL, extract the details I was interested in and put them into a new row in my excel workbook.
In an ideal world you wouldn't need agentic capabilities for this process at all.
You should be able to just make a series of API calls, making a GET request to a given job post URL and look through structured HTML in the response for the fields.

This however is not the reality for the combined following reasons:

Job Posts/descriptions don't all follow the same structure:,
so you'd need an approach which maps to every platform's different approach
i.e. terms used for salary, what headings they put role responsibilities under etc.
Web pages for job posts can be client-side rendered:,
so you may not be able to get the details you're wanting without spinning up a browser environment to render the page in
Where pages are client side rendered important content may not be immediately visible:
so it will need user interaction to reveal, (e.g. clicking a dropdown to find out the Role responsibilities)

I did a search for tools online and did find a few that as it turned out for me used agents to solve the problem.

The only issue being that for one reason or another there was no good fit for my use case, i.e. namely platforms used an agent to get the content needed from a job post but forced using their bespoke spreadsheet software in doing so.

This did lead to me however deciding that bringing AI agents into the extraction process would be a good way to tackle the unpredictability of job posting structures, given I provided appropriate tools, i.e. for rendering/searching page content in the browser.

I therefore embarked after on mapping out the architecture!

Architecture Overview

A high level abstraction of the system architecture, see ARCHITECTURE.MD in the GitHub Repo for the full diagram

Alongside some of my learnings from the ‘Develop Agents with ADK’ skill path I was taking with Google and some research into the ADK docs I drew up a less detailed version of the architecture you see above.
Less detailed as admittedly when I drew up the mermaid diagram my understanding of what was possible and the level of flexibility and efficiencies which could be achieved in composing ADK systems was lower.

I realised this initially, but I decided as this was very much tooling I wanted to meet just my own requirements this was a less relevant concern for me at first (although in retrospect it certainly should have been more relevant!).

I opted to compose the system using a graph based approach in the Google ADK, due to the flexibility offered in declaratively implementing routing and first class support for defining non-agent nodes.
The additional reason being that it would reduce the number of breaking changes I’d have to work through if I wanted to take in any further in future, very much seeming like the sensible option.

1). Handling Composio tradeoffs

Using Composio was a decision that I made under the assumption that it would be safer and less effort than having to implement auth management myself to OneDrive and Excel.
I believe this has held true, however it introduced a large element of non-determinism to the system that had to be handled (not to mention token cost, although it's on the lighter side with using non-frontier models here).

The two major risks posed were as follows:

Wide scope for unrestricted tooling access if the agent decided for some reason an irrelevant tool would solve the problem
Unpredictable response formats in case of runtime errors and even in successful operations!

The first issue was the far easier issue to fix, you could reduce the scope of actions via tools an agent could take through giving a specific allowlist in the Composio SDK to restrict the toolsets and list only the required tools.
Layering on top of this you can provide a clear and specific instruction explicitly mandating specific tools for specific agent nodes.

The second issue of response formats was more difficult to tackle.
Even with a clear and specific instruction and output_schema for the agent to adhere to you can't guarantee what the output format will be, whether the process is a success or an error occurs.

Frankly, there are far too many ways an agent could output that an errors occurred in terms of prose even with a fixed set of failure modes, the same applies to success messages also!

My solution to this was to leverage the ADK's after_model_callback after the agent node had finished all tool calls, intercepting any errors and capture them in the session state under a key of job_spec_details_error (and in which case I set the state job_spec_details to {}).

Only then is the output JSON validated against the Pydantic schema in output_schema.
A subsequent node would then check for errors under job_spec_details_error and surfaces any as user messages before rerunning the agent and (ideally) not running into the issue again.
I set a max retry count of 3 attempts before the system opted to raise an error and exit.

While there are more flexible approaches and more configuration that can be done to improve the system, this approach was sufficient for my purposes.
For example, it would be handy getting an agent to do some light troubleshooting to determine the issue involved and informing the user what's needed to resolve, e.g. API rate limit being met so needing to wait for a period of time before retrying.

2). Flaky gemini models

During development, I've ran a number of times into unavailability of Gemini's flash models.
I can't say I'm too surprised in retrospect as I created a Gemini API Key on the free tier within a test GCP project in Google AI Studio.

However, it's been pretty frustrating when I've been wanting to do some quick tests and been locked out due to model unavailability due to spikes in external usage.

Unless you upgrade the billing tier, I'd recommend as a quicker workaround setting up an environment variable(s) and using these within your agent definitions.
It doesn't solve the root problem but it can be a quicker approach than switching out all agents model fields by hand!

3). Mitigating anti-bot measures

A fair reason why I believe I struggled to find a tool to fix this problem originally is because using agents, web scraping tools or otherwise requires doing your best to mitigate against anti-bot detections and frankly sometimes this isn't always possible.

LinkedIn and Indeed are especially tricky to work around in my experience so far, which can be frustrating when those can be the places you want to target (although frankly I wouldn't advise putting too much focus on Linkedin for searching and making actual job applications - but that's a whole other conversation!)

I created a few custom tools for an agent to use with Playwright which controls a headless chromium instance to navigate and read content from.
This worked all well and fine on more lenient sites for extracting job details, but when it came to Linkedin and Indeed it was a much different story.

With Linkedin, I've decided to give it a pass for now as unless I can use an authentic user-agent (via browser extension control, e.g. chrome) it's pretty tricky.

In addition, you need to be logged in to Linkedin to view jobs which can you put in a tricky situation if you get caught out - perhaps more so than being logged out and getting IP-banned.

However, for other sites I've found using the playwright-stealth python library to be a good mitigation in terms of hiding the tell tale signs of a headless browser fingerprint.

I'll admit this is an area I'm still learning about so I've yet to cover all practical bases here but it's helped me in part here.
Will do my best to update this article around this topic with new approaches as I get stuff sorted here!

Final takeaways/conclusion

Photo by Alexander Grey on Unsplash

If you're tackling an agent-based project with Google ADK and Composio, I'd recommend the following:

🔒 Allowlist needed tools/toolkits only when using Composio
🛡️ Use ADK agent callbacks to safely handle output format errors
⚡ Enable quick model switch-outs with environment variables

Hope you enjoyed reading and the above guidance can be of help for you if you embark on your own project with Google ADK and Composio.

If you do, feel free to comment below as would love to check them out.
Additionally, if you have any further questions around this area send me a message on LinkedIn or comment below and I'll answer to the best of my knowledge!

As an aside, if you'd like to checkout the project check out the repo link below.
I've also attached docs links for some of the topics I've covered here for further reading.

Hope you have a great day!

🔗 Links:

The Learnings & Pitfalls of Building a Chrome Extension

Stephen Ingham — Tue, 28 Jul 2026 17:42:07 +0000

Introduction

If you’ve worked in software development, then you may be familiar with the situation during a busy feature or maintenance sprint where pull requests are being produced left right and centre across a range of your team’s git repositories.

It can be tricky to determine immediately which repositories have active pull requests in need of review when using only conventional tools, e.g. slack threads, email notifications, without a good deal of searching first.

To tackle this issue, I designed and developed a utility chrome extension which allows you to quickly check for any active pull requests on repositories you choose to track. As a result, standing to save you time in the process.

In this blog I will cover my core learnings while developing this extension. However I’ll first give a brief overview of what a chrome extension is and how it compares to your standard web application for context.

Chrome Extensions vs. Web Applications

Photo by Rubaitul Azad on Unsplash

What is a Chrome Extension?

A chrome extension is a small piece of software that runs in the browser, which adds new features or modifies existing functionality. They sometimes offer a user interface (popup) accessible from the toolbar and can be used to perform tasks such as blocking ads or providing translation assistance etc. and are available from the Chrome Web Store.

The Similarities:

Fundamentally, a chrome extension uses the same web technologies as any other web application.

You have:

HTML, CSS and JavaScript files:

These describe your user interface and the logic for your application for execution within the browser environment, as they do for a web application.

JavaScript Frameworks/Libraries and Build Tools:

While not essential, just as it is possible to write web apps without them you are able to use JavaScript frameworks/libraries such as React/Vue alongside build tools such as webpack, babel etc.

The Differences:

The main differences between web apps and chrome extensions lie in how each type of application utilizes the browser under the hood, and the need for an extension to have a manifest.json file.

Difference 1: The manifest.json

At a minimum, a chrome extension needs a manifest.json file. This tells the browser everything it needs to know to load, configure and display the extension. Without this file, the extension would cease to exist.

For example, the manifest.json is needed to inform the browser that the extension needs permission to use storage APIs to store/retrieve data from within the browser’s local storage for instance.

Difference 2: Background and Content Scripts

In order to manipulate the browser, your extension needs a service worker.

For example, a service worker can be responsible for detecting changes to an extension’s local storage or rearranging chrome tabs for example.

A service worker runs as a thread within your browser to execute APIs enabling these activities. However, a service worker cannot directly alter the DOM of webpages you have open.

This is where a content script comes in (or an offscreen document, which won’t be discussed in this blog).

A content script provides APIs which can alter the content/styling of webpages. To coordinate changes to the DOM based on events detected within the service worker as described, a communication chain must be established. This is done by setting up a message passing API between the service worker and content script.

The Power of Browser Extensions:

Compared to a typical web application, setting up a communication chain to manipulate the DOM after a change is detected in the browser requires more work to achieve.

However, the core benefit of this setup is that a chrome extension can access a far greater range of additional, more powerful APIs than a web application can.

For example, a chrome extension can use the Extensions API for handling system access, tab manipulation, searching browser history, network request control functionality among many other purposes.

Reduced API access in Web Applications

Web applications can gain access to a smaller set of browser APIs which pose a lesser risk, such as allowing access to a device’s geolocation.

The reasoning for this architectural difference is due to security risks that web applications cannot mitigate against. Namely, malicious client-side code could be hosted on a web server and stand to use APIs in a myriad of harmful ways against the user.

This is a far less likely occurrence for a chrome extension which would undergo a thorough review process before release on the Chrome Web Store.

The manner of gaining access to the DOM and the more powerful functions chrome extension APIs can perform form the dividing line here. Now we have covered the fundamentals let’s discuss my learnings!

Tip #1 - Invest in creating a Mock for your API Integration

One of my first development mistakes was in accidentally making too many unauthenticated API requests to GitHub in lieu of working with a mock/double.

As I had experienced some initial trouble in setting up a testing environment for the extension, I had consequently put off setting in place a double for the GitHub REST API I could use during local development.

As a result, I was occasionally getting IP locked from making too many unauthenticated requests to the API.

This being, due to the frequency at which I was manually making and then checking small source code changes hadn’t inadvertently introduced bugs during core user flows, which naturally involved making lots of API requests.

The delays encountered due to this were fairly brief as I thankfully recognized them as they came through and aimed to be more intentional with my API calls.

However investing the time in setting up a mock, i.e. dockerized JSON server image or the like, could have definitely saved some time in retrospect.

Tip #2 - Use Plasmo to speed up your development workflow

Something else I wished I invested the time in, was looking further into finding tooling for showing your updated chrome extension’s popup as soon as modifications were made. Namely, I was looking for what many web framework build tools offer, the ability to provision a development server for your chrome extension.

When I started out this project, I did some initial research into this area and wasn’t able to find anything fulfilling this role. My approach was to manually reload the unpacked extension within the developer console after each new build.

I evidently didn’t search hard enough initially, as it was only later I discovered tools such as Plasmo existed for this purpose.

In retrospect, using Plasmo to channel a dev server from my build tool, Vite, would have saved me a lot of time, allowing for a quicker development flow.

Tip #3 - Use the chrome.alarms API to ensure reliable timer/alarms functionality

Later in development I realised I was likely approaching a stage at which I’d be ready to prepare the extension for release on the Chrome Web Store.

However there was still one major issue with functionality that had persisted.

Contrary to my initial assumptions, when the extension popup was closed the mechanism to automatically fetch active pull requests on a user’s tracked repositories also stopped running. This went against the feature requirement I had in providing the user with up to date tracking functionality.

I had naively assumed at first that any code I wrote in the background script would continue to run persistently regardless of whether the chrome extension popup was loaded or not. For example, code running on a loop through the web setInterval API.

This being as this was my experience and understanding in the context of background processes for loaded but inactive chrome tabs.

I presumed the same would apply for a chrome extension which was at the very least loaded in the user’s browser.

This however is not the case as I found the logic I had created to automate fetching of updated pull request numbers would at most run for 30 seconds before the thread died and with it any future scheduled fetches.

This is due to a behavior requirement of extensions using Manifest V3 which enforces service worker threads to be short lived. The aim of this design decision is to minimize browser resource usage, only running continuously if triggering API-related events occurs often enough in the worker.

Thankfully, there is an easy solution to ensure processes occur reliably to a set schedule. This is provided by the chrome.alarms API which offers alarm functionality for creating and triggering resilient alarms.

These alarms awaken the service worker through configured alarm event listeners, which in my case ensured the extension continuously made GitHub REST API calls at set intervals, e.g. every 1 or 5 minutes.

While admittedly a setback, through this experience I learnt a valuable piece of domain knowledge in chrome extension development.

Additionally, it also illustrated the importance of vetting your technical assumptions before planning and implementing architecture. It certainly would have saved me a good deal of time on reflection!

Key Learnings/Takeaways

In summary, when undertaking a chrome extension development project ensure you follow these steps to make your life easier!

🎭 Mock your API
🛠️ Use Plasmo for faster iterations
⏰ Use chrome.alarms for reliable scheduling

I hope this helps you to avoid some of the development pitfalls I ran into when you tackle your own projects!

If you have any questions or thoughts on what I’ve run through here, feel free to drop me a message in the article comments below or directly to my Linkedin profile as I’m happy to help!

Alternatively, if you’d like to check out the repo for the extension the link is below alongside docs you may find interesting.

Hope you have a great rest of your day!

Stephen

🔗 Links:

Github Repo: https://github.com/cyprste2717218/github-prs-chrome-extension
Plasmo Docs: https://docs.plasmo.com/
Chrome Extension Docs: https://developer.chrome.com/docs/extensions