---
id: KB-CL-002
url: https://app.codecontract.io/help/collaboration/what-can-run-itself-and-what-cannot
idioma: en
categoria: colaboracion
subcategoria: automatico
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CF-005, KB-CL-001, KB-CL-019]
citadoPor: [KB-CL-004, KB-CL-010, KB-CL-005, KB-CL-006]
---

# What can run itself and what cannot

_Where automation ends and a person becomes necessary._

**Responde a:** automate document management · what can be automated · what automated agents do · let the system work by itself

The question that always comes is how much of this can be left running on its own. The honest answer: considerably more than people think on the repetitive side, and none of what decides.

## The boundary

| Runs itself | Needs a person |
| --- | --- |
| Requesting the usual documents from the right people | Deciding whether a supplier is still worth keeping |
| Chasing at days 3, 7 and 12 | The day-15 phone call, when chasing has stopped working |
| Warning about expiries with margin | Negotiating the renewal |
| Reading a document and extracting its dates | Deciding whether that document is acceptable |
| Marking approved what meets every criterion | Approving what meets almost all of them |

Notice the pattern: what can be automated is whatever has a clear rule. The moment a "it depends" appears, someone is needed.

> [!IMPORTANT]
> Do not automate approval of anything with consequences. Having the system mark as approved whoever meets every criterion is fine; having it approve whoever nearly meets them is delegating a decision that remains yours if something goes wrong.

## The reasonable target

Not 100%. It is that 85% closes itself and people spend their time on the 15% that needs judgement — which is where a person actually adds something.

> [!WARNING]
> Be careful automating a process that is still changing. If the process is not stable, the automation breaks fortnightly and creates more work than it removes.

> [!NOTE]
> Before automating something, do it by hand three times. That is what shows you where the exceptions are, and exceptions are what break automation.

**Can I review before something automatic goes out?**

Yes, and it is wise at first: review, confirm it gets it right, then let it run.

**Can everything be stopped if something goes wrong?**

Yes, and it is worth knowing how before you need it.

**Is what the system did recorded?**

Yes, the same as what a person does.

## Ejemplos

**A company wants to automate supplier approval end to end.**

- Automates requesting, chasing and clearing whoever meets everything
- Leaves the near-misses to a person

→ 85% closes itself and the exceptions are decided by someone who answers for them.

**The reminder is automated and the team expects it to also decide whether a document is valid.**

- Automates what needs no judgement: requesting, chasing, warning
- Leaves approval with whoever has the judgement
- Checks what is happening automatically before relying on it

→ The repetitive stops occupying anyone and what needs judgement still has an owner.

**Approval is automated and expired documents get through.**

- Automates the date check and leaves the rest for review

→ What is checkable is checked automatically and what is doubtful reaches a person.

**Nobody knows what the system is doing on its own.**

- Checks which rules are active

→ The automatic behaviour is known.

**A rule has been active a year and no longer makes sense.**

- Reviews the rules when the process changes

→ The system does what the company needs today.

**Something that happens twice a year is automated.**

- Automates what repeats every week

→ Effort goes where there is repetition.

**A rule is switched off and nobody knows what stopped happening.**

- Notes what it did before switching it off

→ The gap is visible rather than discovered.

**Two rules do the same thing and the supplier gets two notices.**

- Checks for overlap before adding a new one

→ The recipient receives a coherent message.