Software was meant to be means to an end

Before we begin, I want to state that these are solely my own musings and don’t represent that of my current employer.

When I first entered the job market around a decade ago. Software was ubiquitous in the domain of logistics. New entrants were assessed by their proficiency of tool for getting hired.

Most of software was still on premise, licenses were sold and distributed through servers or CD-ROMs.

The SaaS shift was in full swing which was further accelerated with the launch of mobile platform.

In the domain of logistics, knowing how to use TMS software was pertinent to getting hired on the operations team of a logistics service provider.

This led to a boutique sector of coaching classes where young graduates who are looking for employment are trained.

For example, coaching classes are available for every software with a job market. An example of a coaching centre in Hyderabad’s famous location.

My own motivation to shift to product design stemmed from the challenge of using such software in the domain of logistics.

After access to mobile and being a user of consumer software, the design of the legacy software was frustrating. The outdated designs were triggering enough for me to pickup Sketch and spend few years doing work as a product designer.

Design has to be accessible and craft of it involved thinking through the entire system and encoding it into a UI for end user. It still required getting used to but the onus was now on the software to orient the user.

In the previous issue I wrote how agents can run now longer and complete tasks at a fraction of cost. Thus, leading to a wider set of capabilities that can be executed autonomously.

One such capability would be using legacy software itself. Instead of training humans on tool use, why don’t we train agents to execute workflows on the software to get the job done.

In the past, the entry level roles like Operations co-ordinator was mostly scoped to keying in data into TMS. As the person gains more experience in the domain, they move further away from software. They become focused on training, leadership and guidance of other humans who are using the software. With increased expertise in domain, software use reduces in their day to day role.

The entry level role always has high churn due to low paying and repetitive nature of job. Also, only few move up the hierarchy due to how organisations are structured. This setup leads to a significant investment in hiring, skilling and training people on a continuous basis. Inadvertently the investment causes the role to be low paying.

Now, there is a potential for an agent to do this repetitive job of using software. If the SaaS software tool has API or MCPs, it becomes even much native experience.

Lets suppose you have an on premise software that requires considerable training for a human to operate. Instead, you build the right scaffolding(fancy way of saying infrastructure for building)for an agent to operate on the system.

Suppose you need to enter an order from a customer receipt into your TMS. Agent can process the receipt and create an order in your TMS.

Building the right scaffolding requires agent orchestration, RAG setup, human feedback and evaluation framework to ensure the output is accurate and dependable.

This can be made accessible with certification similar to what humans receive for completing a vocational course. A certified agent removes the onus of execution on the company using the software to the company providing agentic labour to use software.

When we talk about displacement of jobs, we are talking about roles like Operations co-ordinator no longer being available. The workflow will still be executed since the nature of software in legacy domains is often for systems of record.

You might think what would then humans do?

They can actually spend time learning the domain. We still have people in logistics who are good at excel think they are good at operations. The vocation is not given high priority because using software keeps the workforce busy. And, it is framed as right of passage.

This is an opportunity to bridge that divide and have software irrespective on its stack be part of the workflows in legacy domains like Logistics.

Round up

I read Tom’s post and was thinking of encoding expertise for agents to leverage.

Is this just a skill

…

A skill is enough when the value is in the knowledge, not the infrastructure.

If what you're building is essentially "here's how to do this thing well", a methodology, a process, a set of decision rules, a framework for thinking through a problem that's probably a skill. The AI agent provides the interface. The skill provides the expertise.

Skill writing is a form of point of view of the operator looking to deploy their team. It’s an act of explicitly documenting the tacit knowledge one gains through practice and deliberation.

Curating skills and letting an agent access them helps one expand their scope of control exponentially in doing the job.

Links that resonated

First one comes from Benn Stancil who writes how work had become less of a burden and more of a play thing.

Something good

Second one is from Mario Zechner suggesting developers to slow down and be careful with speed of agents.

Thoughts on slowing the fuck down

Sign off

Work has been intense. I have been feeling the after affects of it throughout the week. Its similar to how one feels after a big game of a sport. Your body is sore from extending yourself during the game.

I am using CLI (command line Interface) to interact with agents but most importantly I am moving away from building a codified artefact in a chat session towards a project on my local machine. I can iterate on it further once I get feedback from using it and don’t have to worry about context of the chat.

Its still early days but I get what Benn mentioned in his post. I am having fun building this digital artefacts using agents.

If a picture is better than thousand words, I would frame a prototype to 10x the word count. So, 10,000 words of written word subverted by a functioning prototype to communicate the objective.

Hence, most of my writing at work is for an audience of 1, the agent building the prototype.

Signing off till next time,

Vivek , back to sipping coffee after a 8 month hiatus.