Notes from a data scientist to the leaders who staff and govern AI agent projects
I read a lot of AI engineer job descriptions out there asking for the same things: "3+ years of LangChain, experience with CrewAI, Google ADK a plus." I understand why. Framework names are concrete, recruiters can screen for them, and candidates who list them look ready to work on day one.
My reaction to this in one sentence: the skills that make an AI agent safe and reliable carry across frameworks, and these skills deserve more weight in hiring decisions and training than mere familiarity with any one tool.
What they have in common is process design.
A scenario worth thinking through
Picture a customer service agent that processes refunds. Three months after launch, it refunds an order that is 45 days old, against a 30-day policy. Finance catches it at month-end.
In a case like this, the root cause often has little to do with how well the engineer knew the framework. The code can be clean and idiomatic while three design decisions went unmade:
- A check on the refund policy before the agent acts,
- An amount above which a person must approve,
- And a log of decisions an auditor can follow.
The major frameworks, LangChain/LangGraph, Google ADK, AWS's Strands Agents, and CrewAI, all provide the building blocks for those three controls. Deciding to build them, and where, is a design skill.
What I see in the frameworks themselves
Agent frameworks change quickly:
LangChain released version 1.0 in October 2025 and introduced a new "middleware" system as its recommended way to customize agent behavior.
Strands Agents shipped its "steering" feature as experimental, then moved it elsewhere in the library.
CrewAI introduced a new, unified way to write checks around agent actions, and its documentation now describes the older approach as more limited.
Google ADK still labels its support for reusable "skills" as experimental.
At the same time, the four frameworks converge on the same core mechanisms: points where engineers can inspect and control what the agent does before and after it acts.
These two observations suggest that knowledge of a framework's syntax loses value with each release, while understanding of the underlying patterns keeps its value. An engineer who understands the patterns can usually pick up a new framework's version of them without starting over.
Framework choice can also shift for reasons outside engineering: a cloud contract, an acquisition, a client requirement. If that has happened in your organization, you have seen how framework-tied skills turn a business decision into a retraining project.
Five capabilities, translated into business risk
Engineers call the layer of controls around an AI model the harness. You don't need to know how to build one. I think it helps to recognize its main parts, because each one relates to a risk that sits with leadership.
| Engineering concept | What it does | Risk it helps control |
|---|---|---|
| Hooks and callbacks | Code that runs before or after the agent calls the model or takes an action | Unauthorized actions, data leaks, gaps in the audit trail |
| Guardrails and approval gates | Rules that block an action or pause for a person to approve | Financial loss, regulatory breaches |
| Steering | Checks that correct the agent at the moment it drifts from policy | Inconsistent policy application on long tasks |
| Skills | Packaged, versioned procedures the agent loads when a task needs them | Loss of process knowledge, uneven execution across teams |
| Scope and ordering of controls | Decisions about which rules apply company-wide and in what order checks run | A security check skipped because another check ran first |
In the refund scenario, a hook would log each refund decision, an approval gate routes large refunds to a team lead, a steering check stops the agent from refunding before it verifies the order date, and a skill holds the refund procedure in a form your operations team can read.
Skills: an opening for HR and operations
A skill is a folder with a plain-text instruction file (SKILL.md) and supporting documents. It reads like a procedure:
> ---
>
> name: refund-policy
>
> description: Rules for processing customer refunds. Use when a customer asks for a refund or return.
>
> ---
>
> 1\. Look up the order before doing anything else.
>
> 2\. Refuse refunds on orders older than 30 days; offer store credit instead.
>
> 3\. Refunds above 500 EUR require approval from a team lead.
The format started at Anthropic and has become a shared specification that LangChain, Google ADK, Strands and CrewAI can all load. A few possibilities follow from that, depending on how your organization works:
Domain experts can co-author agent behavior. An HR policy lead owns the skill behind an internal assistant that answers parental-leave questions. A compliance officer reviews the skill for KYC checks.
Skills can be governed like policies. They live in version control with a change history, so you can require sign-off on edits.
The asset outlasts a framework change. Moving from one framework to another does not require rewriting the skill library.
If this makes sense to you, it points to a new kind of role: people who know a business process well enough to write it down step by step, and know AI agents well enough to spot the gaps. Some of them may already work in your operations, quality or compliance teams.
Where framework depth does matter
Frameworks differ in deployment, monitoring and how they handle long-running tasks, and each has pitfalls only experienced users know. Design skill doesn’t replace that. A team shipping on Google Cloud next month benefits from someone who knows ADK in depth. A small team under deadline pressure is right to hire for the exact stack it runs.
So I don't see this as framework knowledge versus design skill. It is a question of balance: what you screen for across the team, and where you place deep specialists.
Some ideas you might adapt
The examples below are starting points. You can adjust them to your size, stack and risk profile.
A job description variant
A common version:
Requirements: 3+ years of experience with LangChain and LangGraph. Hands-on experience with CrewAI. Familiarity with Google ADK is a plus.
An alternative that asks for evidence of design skill:
You will build AI agents that act on behalf of our customers and employees. We would like to see evidence that you can:
Design controls around an agent: checks before and after actions, approval steps for high-risk actions, and logs an auditor can follow.
Decide which rules belong in code, which in an AI-based reviewer, and which need a person.
Work with domain experts to package procedures as reusable skills.
We use [framework] today. Production experience with any major agent framework qualifies.
A possible benefit is a wider candidate pool, since a strong ADK engineer becomes a fit for a LangChain role. A trade-off is a longer ramp-up on your specific stack, which you would want to weigh against your timelines.
An interview exercise
If framework keyword screening gives you mixed results, a design question reveals more:
An AI agent handles expense reimbursements. It can read receipts, check the travel policy and approve payments. What controls would you put in place before launch?
A few signals I would look for:
| Encouraging | Worth probing |
|---|---|
| Separates hard limits (in code) from judgment calls (human review) | "I'd put the rules in the prompt" |
| Thinks about what the agent tells the employee when a control blocks it | Blocks actions with no explanation path |
| Raises human approval and where its record is stored | No mention of human oversight |
| Distinguishes company-wide rules from rules for this agent | Treats all rules the same |
| Explains how the design maps to a framework they know, and what they would look up in another | Recites function names without explaining design |
A useful follow-up: "If we switched frameworks next quarter, what would you rewrite and what would you keep?"
An upskilling path
For an existing team, one approach is to move expertise up a level without replacing anyone:
| Phase | Rough duration | Activity | Output |
|---|---|---|---|
| Map | ~2 weeks | Engineers describe the controls in one existing agent in plain language | A control inventory |
| Cross-train | ~4 weeks | Pairs rebuild one control in a second framework | A shared translation guide |
| Codify | ~4 weeks | Engineers and process owners turn top procedures into skills | A reviewed skills library |
| Review | Ongoing | Regular design reviews against a common checklist | More consistent controls |
The durations are estimates; your team's size and workload will set the real pace. I expect that rebuilding the same control in a second framework does the most to shift people from thinking in syntax to thinking in design.
Questions for a leadership conversation
Regulation adds weight here. If one of your agentic systems falls into a high-risk category under the EU AI Act, you will need to demonstrate human oversight and record-keeping, and those obligations translate into the approval gates and logging described above. Your legal team will know whether and when that applies to you.
If you want to test where your organization stands, these questions help start the conversation:
For each agent in production, which actions can it take without human approval, and who set that threshold?
Where are the agent's business rules written down, and who in the business owns them?
Could we produce a readable record of why an agent took a specific action last week?
If we changed framework or cloud provider, which parts of our agent investment would we keep?
Do our job descriptions and interviews test for the capabilities above?
To close
When you decide what to hire, train and reward in AI agent work, give design skill at least as much weight as tool familiarity. The frameworks will keep changing. The need to control what an agent does, and to prove it, will stay.
Sources
LangChain documentation, middleware and Deep Agents skills: docs.langchain.com
Google ADK documentation, callbacks, plugins and skills: google.github.io/adk-docs
Strands Agents documentation, hooks and steering: strandsagents.com
CrewAI documentation, execution hooks and skills: docs.crewai.com
Agent Skills specification: agentskills.io
Regulation (EU) 2024/1689 (AI Act): eur-lex.europa.eu
Top comments (0)